Bug 152474 - SOLUTION: Erase character wrong in screen
Summary: SOLUTION: Erase character wrong in screen
Alias: None
Product: Fedora
Classification: Fedora
Component: screen   
(Show other bugs)
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Petr Rockai
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-29 20:36 UTC by Need Real Name
Modified: 2008-08-02 23:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-25 20:05:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2005-03-29 20:36:42 UTC
+++ 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
it doesn't.

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

Comment 1 Need Real Name 2005-03-29 21:03:57 UTC
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 */
#include <stdlib.h>

int main( void )
        int ret;

        ret = system("/bin/stty -a|less");
        return ret;

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
display ^H^H^H....

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
should suffice:

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.


Comment 2 Need Real Name 2005-03-29 21:16:26 UTC
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.

Comment 3 Matthew Miller 2005-04-26 16:34:40 UTC
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.

Comment 4 John Thacker 2006-10-25 20:05:43 UTC
Closed per above message and lack of response.  Note that FC2 is not even
supported by Fedora Legacy currently.

Note You need to log in before you can comment on or make changes to this bug.