+++ This bug was initially created as a clone of Bug #11294 +++
Virtual terminal in screen don't send ^H for delete(backspace)
as they should, but ^?.
Tested on the console and xterm.
The screen termcap entry says that the delete character (kb)
is ^H , also the man page says that screen maps "physical"
terminals delete character to ^H by default, but on RH6.2
A quick fix is to add a line in the file screenrc ( either
/etc/screenrc for system wide effect or $HOME/.screenrc for
per user effect ) :
bindkey -d -k kb stuff \010
I cloned this bug because I couldn't find a way to change the status of the
original to re-open it.
I think I have this problem pinned down, though I'm still not 100% sure WHY it
happens... The problem appears to be this:
Any program started in screen (i.e. exec'd by a shell which screen has started)
seems to work fine. However, any program started by forking in those processes
exhibits the problem.
You can demonstrate the problem very easily by starting screen, and then
compiling and running the following tiny program:
/* test_screen.c */
int main( void )
ret = system("/bin/stty -a|less");
Once less is running, hit '/' to start a search pattern. Type some stuff. Now
hit the backspace key. Rather than backspacing properly, the terminal will
PROBLEM: Forked programs appear to rely on the erase setting of stty, rather
than looking at terminfo. FWIW, this is probably the correct behavior of ALL
programs. I say that because the system will normally initialize erase to the
default defined in the terminfo db, and if the user uses stty to change it,
there is probably a really good reason for him doing so...
SOLUTION: There is no problem whatsoever if screen is going to use ^H
internally and translate that to the physical terminal's erase character.
However, screen must change the (pseudo) terminal's erase character to ^H in
order for all programs to see this translation. Since screen opens a pseudo tty
for each of its screens, there should be no need to save the original setting of
the controling terminal... Meaning, this should be a one-line patch to screen
to set the erase character on all opened pseudo ttys.
WORKAROUND: Until this fix hits the source code, the following in .bashrc
if [ "$TERM" = screen ]; then
stty erase '^H'
The RIGHT way to work around this problem SHOULD be to use tset in your .bashrc
file. I tried solving this by running tset in my .bashrc, like this:
tset -Q -e
This SHOULD set the erase character based on the terminfo database's idea of
what it should be, and indeed my tests suggested that it did that fine.
However, it also caused a strange echo effect as a side effect. It repeated
non-control characters, and for control characters, it displayed the hat
notation for the character in addition to sending the control character to the
terminal. Very strange.
Setting the erase character conditionally based on the value of $TERM is a
little gross, but it works flawlessly.
Please fix screen so that it resets the (pseudo) terminal's erase character to ^H.
Note that this bug report was originally filed against Red Hat 6.2, but I have
experienced it in Red Hat 9 and Fedora Core 2.
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Closed per above message and lack of response. Note that FC2 is not even
supported by Fedora Legacy currently.