Maybe it was always sending Delete and I didn't notice it, but I have had the following in my .tcshrc file for ages (without realizing it):
bindkey -b ^? i-search-back
Before the update to 4.4, hitting the backspace key at the shell prompt deleted the previous character. Now it activates the search backwards function as instructed to do so by the bindkey directive. The question is, what changed to cause this? I never realized I had that bindkey statement (I have never used the search backwards function). Is this a change in tcsh? Has something changed in the X server? Here is the output from xev when pressing and releasing the Backspace key:
KeyPress event, serial 28, synthetic NO, window 0x2800001, root 0x48, subw 0x0, time 1593248, (136,112), root:(179,193), state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) " XmbLookupString gives 1 bytes: (08) " XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2800001, root 0x48, subw 0x0, time 1593358, (136,112), root:(179,193), state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) "
If I remove that bindkey command from my .tcshrc file, the Backspace key removes the previous character as expected. However, hitting Backspace in vim inserts ^? into the file (with or without the bindkey setting). Anybody else seen this? I've removed the bindkey statement from my .tcshrc file, but it's still annoying me in vim that I can't hit Backspace to delete the previous character...
Alfred
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry for the top posting, but this is one of the cases there I think it applies.
I also noticed this change. I use bash, so this is not exclusive to tcsh.
I had to add "stty erase ^?" on my .profile to solve this one.
On the other hand, this MIGHT be the correct behaviour. When using the console on older version, we would already have ^?. When on xterm, we would get ^H. At least now the behaviour is consistent.
On Sat, Sep 02, 2006 at 07:11:03PM -0400, Alfred von Campe wrote:
Maybe it was always sending Delete and I didn't notice it, but I have had the following in my .tcshrc file for ages (without realizing it):
bindkey -b ^? i-search-backBefore the update to 4.4, hitting the backspace key at the shell prompt deleted the previous character. Now it activates the search backwards function as instructed to do so by the bindkey directive. The question is, what changed to cause this? I never realized I had that bindkey statement (I have never used the search backwards function). Is this a change in tcsh? Has something changed in the X server? Here is the output from xev when pressing and releasing the Backspace key:
KeyPress event, serial 28, synthetic NO, window 0x2800001, root 0x48, subw 0x0, time 1593248, (136,112), root:(179,193), state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) " XmbLookupString gives 1 bytes: (08) " XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2800001, root 0x48, subw 0x0, time 1593358, (136,112), root:(179,193), state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) "
If I remove that bindkey command from my .tcshrc file, the Backspace key removes the previous character as expected. However, hitting Backspace in vim inserts ^? into the file (with or without the bindkey setting). Anybody else seen this? I've removed the bindkey statement from my .tcshrc file, but it's still annoying me in vim that I can't hit Backspace to delete the previous character...
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry for the top posting, but this is one of the cases there I think it applies.
I also noticed this change. I use bash, so this is not exclusive to tcsh.
I had to add "stty erase ^?" on my .profile to solve this one.
On the other hand, this MIGHT be the correct behaviour. When using the console on older version, we would already have ^?. When on xterm, we would get ^H. At least now the behaviour is consistent.
The correct behaviour for the backspace key is to send the BS character, 0x08 aka ^H.
^? I suspect is the DEL character, 0x7f, which is unprintable (or prints as a space). I would expect the Delete key to produce a DEL character.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Sep 03, 2006 at 08:11:18AM +0800, John Summerfield wrote:
The correct behaviour for the backspace key is to send the BS character, 0x08 aka ^H.
^? I suspect is the DEL character, 0x7f, which is unprintable (or prints as a space). I would expect the Delete key to produce a DEL character.
The correct behaviour for who ? For many platforms (Sun is the first one that comes to memory), the correct backspace char was always ^?
At least here, for me, DEL shows are ^[[3~ (ANSI code ?!?).
Yes, on ASCII, DEL is 7F and BS is 08. But remember the issue here are not charsets, but console control codes, which usually are the same, but not always.
The definition is kind of iffy, but on the console_codes manpage it states that, for Linux BS should indeed produce ^H. But lets remember that is Linux specific, and might not be true to many other platforms.
Things that could be affecting this:
termcap (Built on Feb 2005) ncurses (Bult on Feb 2005) xterm (Built on May 2006) [CentOS 4.3 maybe?]
and probably some other things I'm missing.
One thing to circunvect this problem (on xterm at least) is to add:
*xterm*backarrowKey: true
on your ~/.Xdefaults file, or one of the systemwise equivalents (/etc/X11/Xresources). It will change the xterm behaviour to the way it was before.
KDE terminal (konsole) will use these xterm settings without any problems, but for gnome-terminal you might need a little something extra:
*gnome-terminal*backarrowKey: true
And now I can name the culprid for the problem, and it is the xterm package.
The file: /usr/X11R6/lib/X11/app-defaults/XTerm
on 4.4 has some VT100 extra lines, including these one:
! keyboard setup *VT100*backarrowKey: false
If you remove/comment the second one, and then reload the resources:
xrdb -remove xrdb -load /etc/X11/Xresource
Your (xterm|konsole|gnome-terminal) will start working again as before.
Beats me why this didn't show up before, but then again, maybe it did and I missed it.
If you only want to fix it for your user, and have no risk of it getting screwed up on the next update, do this:
echo "*VT100*backarrowKey: true" >> ~/.Xdefaults xrdb -merge ~/.Xdefaults
Close your terminal windows (xterm, konsole, gnome-terminal), and open it again. The new one will have ^H as the BS character.
NOTICE: This e-mail is bouncing all around cause I was writing it as I tested. I decided to leave it as such, since most people around don't understand about X Resources, and this could provide some interesting pointers for learning.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sep 3, 2006, at 20:21, Rodrigo Barbosa wrote:
One thing to circunvect this problem (on xterm at least) is to add:
*xterm*backarrowKey: true
Or you can do a "xterm -xrm '*xterm*backarrowKey: true'" as well. The funny thing is, I thought I tried this, but I couldn't get it to work (I must have made a typo in the resource name).
And now I can name the culprid for the problem, and it is the xterm package.
The file: /usr/X11R6/lib/X11/app-defaults/XTerm
on 4.4 has some VT100 extra lines, including these one:
! keyboard setup *VT100*backarrowKey: false
Excellent detective work! I'll check what this file looks like on our systems at work (which are still running CentOS 4.3) when I get back into the office on Tuesday.
This e-mail is bouncing all around cause I was writing it as I tested. I decided to leave it as such, since most people around don't understand about X Resources, and this could provide some interesting pointers for learning.
I used to be an X-Windows developer, so I am very familiar with resources, but I had forgotten where the default resources are kept.
Alfred
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Sep 03, 2006 at 09:15:38PM -0400, Alfred von Campe wrote:
This e-mail is bouncing all around cause I was writing it as I tested. I decided to leave it as such, since most people around don't understand about X Resources, and this could provide some interesting pointers for learning.
I used to be an X-Windows developer, so I am very familiar with resources, but I had forgotten where the default resources are kept.
Ehehehe. The last time I did X developing was for X11R3 on a AIX workstationg. AIX 3.2.3, if I recall correctly. A LONG time ago. I don't even have my X bible set anymore (donated them to a school). Took some time to remember this problem could be caused by it.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Sep 03, 2006 at 08:11:18AM +0800, John Summerfield wrote:
The correct behaviour for the backspace key is to send the BS character, 0x08 aka ^H.
^? I suspect is the DEL character, 0x7f, which is unprintable (or prints as a space). I would expect the Delete key to produce a DEL character.
The correct behaviour for who ? For many platforms (Sun is the first one that comes to memory), the correct backspace char was always ^?
By definition of the American National Standards Institute.
At least here, for me, DEL shows are ^[[3~ (ANSI code ?!?).
Those are character interpretations, not the underlying codes. They are ANSI control sequences for controlling terminals. I suspect they originated with the Digital Equipment Corporation, possibly with its VT100 glass teletypes.
The backspace character's original purpose was to tell a printer-keyboard to back space one position, so the next chracter would overtype the previous: it was exactly opposite to a space.
The DEL character is also known as RUBOUT. Why?
In the olden days, we used paper tape. Nobody wanted to throw out, or rekey, a roll of paper tape because of a small error. How do we fix a wrong character/ We rub it out. We punch holes across the tape, and so the value 0x7f (remember, ASCII is a seven-bit code). A program reading data from paper tape had to recongise special control characters; one of them was DEL, which it simply dropped.
Yes, on ASCII, DEL is 7F and BS is 08. But remember the issue here are not charsets, but console control codes, which usually are the same, but not always.
The definition is kind of iffy, but on the console_codes manpage it states that, for Linux BS should indeed produce ^H. But lets remember that is Linux specific, and might not be true to many other platforms.
thank your for writing
but my question was about connecting to the internet
thanks anyway
barbaara fberg wrote:
thank your for writing
but my question was about connecting to the internet
thanks anyway
1. Pruning is good, but, Barbaara, please quote enough of what you're replying to, so people can more easily understand what you're talking about.
2. Why do you think Rodrigo was responding to you?
On Sep 2, 2006, at 19:30, Rodrigo Barbosa wrote:
I also noticed this change. I use bash, so this is not exclusive to tcsh.
I had to add "stty erase ^?" on my .profile to solve this one.
tcsh actually handles it correctly (unless you remap ^? to something else). But this is still an issue in vim (and possibly other applications as well).
On the other hand, this MIGHT be the correct behaviour. When using the console on older version, we would already have ^?. When on xterm, we would get ^H. At least now the behaviour is consistent.
I don't know if it's correct behavior or not, but it's certainly changed behavior. I'm trying to figure out what changed (and why).
Alfred
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Sep 02, 2006 at 10:03:14PM -0400, Alfred von Campe wrote:
On Sep 2, 2006, at 19:30, Rodrigo Barbosa wrote:
I also noticed this change. I use bash, so this is not exclusive to tcsh.
I had to add "stty erase ^?" on my .profile to solve this one.
tcsh actually handles it correctly (unless you remap ^? to something else). But this is still an issue in vim (and possibly other applications as well).
If you use stty, vim and everything else will work fine.
On the other hand, this MIGHT be the correct behaviour. When using the console on older version, we would already have ^?. When on xterm, we would get ^H. At least now the behaviour is consistent.
I don't know if it's correct behavior or not, but it's certainly changed behavior. I'm trying to figure out what changed (and why).
I agree. This kind of change on a non-major update is disturbing.
Then again, I'm used by now on getting different behaviour on this one for every linux distro I have to use (not to mention Solaris, AIX etc), so I really don't worry about it.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sep 2, 2006, at 22:11, Rodrigo Barbosa wrote:
If you use stty, vim and everything else will work fine.
Yes, but that's "cheating". I would have to conditionalize it in my .tcshrc file so it only does it on CentOS 4.4 systems.
I agree. This kind of change on a non-major update is disturbing.
Well, I don't think it's quite as bad as "disturbing", but it has definitely made me curious to find out what the change was.
Then again, I'm used by now on getting different behaviour on this one for every linux distro I have to use (not to mention Solaris, AIX etc), so I really don't worry about it.
That's a good point. Maybe doing a "stty erase ^?" is not so bad after all and will work on most (all?) UNIX like systems.
Alfred
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Sep 02, 2006 at 10:28:36PM -0400, Alfred von Campe wrote:
On Sep 2, 2006, at 22:11, Rodrigo Barbosa wrote:
If you use stty, vim and everything else will work fine.
Yes, but that's "cheating". I would have to conditionalize it in my .tcshrc file so it only does it on CentOS 4.4 systems.
Pretty standard stuff, really :)
Then again, I'm used by now on getting different behaviour on this one for every linux distro I have to use (not to mention Solaris, AIX etc), so I really don't worry about it.
That's a good point. Maybe doing a "stty erase ^?" is not so bad after all and will work on most (all?) UNIX like systems.
Errr, no. You will have to use "stty erase ^H" on many others too. I usually have a big if/else condition on my .profile to do it automatically for me.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm providing a summary here for easy searching, including the problem and the solution. I tried adding it to the CentOS Wiki, but unfortunately I don't have permission.
The problem started with xterm-192-1.EL4.0. CentOS 4.4 includes version 192-4.EL4, while CentOS 4.3 includes 192-1 (before the change).
when the following lines (along others) were added to the XTerm resource files, located at: /usr/X11R6/lib/X11/app-defaults/XTerm
Other relevant resource files might include UXTerm and XTerm-color, on the same directory.
The lines (2):
! keyboard setup *VT100*backarrowKey: false
This particular resource will cause all VT terminals to disable the backarrowKey feature, which means BS will no longer send ^H, but will send DEL instead (^?).
To test this behaviour, open an xterm, and use Control-LeftButton to open one of the configuration windows (hold the left button of your mouse down), selecting the "Backarrow Key (BS/DEL)" option. When enabled, you get ^H. When disabled, you get ^?.
The least intrusive way to fix this is to create a .Xresources file on the user home directory (~/.Xresources), adding the following like:
*VT100*backarrowKey: true
After that, you can either restart X (Control-Alt-Backspace is great for it, also "telinit 3; telinit 5" as root), you just merge this new value:
xrdb -merge ~/.Xresources
NOTE: On my previous e-mail, I mentioned .Xdefaults, which was the correct name for older versions of X11. Sometime along the way, you was renamed to .Xresources. If you use .Xdefaults, it will not be loaded automaticaly.
You can, of course, edit the XTerm resource file directly, or /etc/X11/Xresources, but you can (will?) have problems on future updates.
The great advantage of this method is not loosing it on a future update.
In any case, you will have to close your terminal windows and reopen them for the change to take effect.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2006-09-03 at 21:39 -0300, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm providing a summary here for easy searching, including the problem and the solution. I tried adding it to the CentOS Wiki, but unfortunately I don't have permission.
Since often valuable stuff like this, which *does* take some effort, goes unacknowledged, I want to say thanks. And plant the seed in others' heads to appreciate it regardless of public ack.
<snip>
-- Bill
-
Alfred von Campe -
barbaara fberg -
John Summerfied -
John Summerfield
-
Rodrigo Barbosa -
William L. Maltby