Bug 11294 - Erase character wrong in screen
Erase character wrong in screen
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
:
: 13281 98752 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-08 05:29 EDT by David Balažic
Modified: 2007-04-18 12:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-17 17:25:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Balažic 2000-05-08 05:29:18 EDT
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 h0e 2000-06-04 01:30:24 EDT
Yah, this problem is getting up my goat too.
Screen by default starts bash.. and this problem isn't evident in bash because
the readline library recognises ^? and ^H as backspace characters, but in
ordinary cooked input (try backspacing over what you type in the "cat" command)
and in ncurses apps (try backspacing over your search pattern less's / command)
..it won't work :)
You could change screen's terminfo so kbs = ^?, but then terminals such vt100
that the windows telnet clients like would have similar problems in screen, and
I think I read somewhere that it was for these clients that the value was
changed to ^H in the first place. It seems to me like screen needs code to
translate between the physical terminal's kbs and it's own kbs.
Comment 2 Jason Merrill 2000-06-13 16:17:08 EDT
This is annoying me, too.  Why can't screen just inherit kbs from the physical 
terminal?  That would be less correct than translating between them, but should 
be simple to implement and better than the current situation.

I'm not a big fan of the erase character changes in 6.2; suddenly I have to use 
stty erase, which I previously haven't had to do on any platform except HPUX.  
In addition to the screen problem, logging in from the terminal program I use 
under Windows (SecureCRT) also incorrectly gets ^H as the erase character.
Comment 3 Jason Merrill 2000-06-13 16:36:52 EDT
Actually, it seems that the screen termcap does inherit kb from the attached 
terminal when a new console is created, but sets the erase character to ^H 
regardless.

I should note I am strongly opposed to translating DEL to ^H in screen, as I 
like to run emacs under screen; the other way around would make more sense.
Comment 4 Bill Nottingham 2000-07-21 10:24:24 EDT
*** Bug 13281 has been marked as a duplicate of this bug. ***
Comment 5 h0e 2000-07-21 11:24:35 EDT
I don't understand how screen can simply inherit kbs? the terminfo database is
fixed, how can you have a variable backspace key?

I was under the impression screen sets erase to whatever the screen terminfo
entry says kbs is
Comment 6 Richard Allen 2000-07-23 14:46:37 EDT
Is there any reason why RedHat doesnt revert to the 6.1 and older behavior of
the backspace
key ?   It really annoys me that every time I telnet/rlogin/ssh to a non linux
system, be it
HP-UX, Solaris, AIX, NCR or whatever that backspace is always ^?
Is there a quick fix for this problem ?
Comment 7 David Balažic 2000-07-26 03:59:11 EDT
It seems that the terminfo/termcap entry for 'screen' says
that 'kbs' is ^H. The man page for screen also says that
screen will convert the 'kbs' char of the "real" ( "physical" )
terminal to ^H. But when I run screen on VT1 it translates
'kbs' ( which is ^? on real VT1 ) to ^? in screen.
This causes problems with all programs that respect terminfo/termcap
and expect ^H.
Comment 8 Crutcher Dunnavant 2000-08-03 16:14:28 EDT
The 'Right Thing' is nasty and requires that I find character translation in
screen.
The dirty hack works now, and screen 3.9.6 is comming,
so well see if they fixed this in that.

Meantime, I used the fix suggested by david.balazic@uni-mb.si,
namely an hackish entry in /etc/screenrc

Closing, screen is now at 3.9.5-11
Comment 9 Need Real Name 2001-03-27 08:23:53 EST
This change is worse than the previous state for people like myself who run
emacs under screen.  I've reverted the change to /etc/screenrc on my machine. 
Why not just change the erase character in the screen terminfo to DEL?
Comment 10 David Balažic 2004-06-18 07:59:40 EDT
But resurrected in Fedora Core 2 ( screen-4.0.2-2.i386.rpm ).

I believe the 'Right Thing' is to change in file term.c line

- { "kb", T_STR  },
+ { "kb", T_STR  }, KMAPDEF("\010")

And the "bindkey -d -k kb stuff \010" can be removed from screenrc (
it already is removed in screen-4.0.2-2 )

Note, that I did not test the suggested change (yet).
Comment 11 David Balažic 2004-06-18 08:10:11 EDT
(forgot to reopen the bug)

I tested the above patch and it works.
Comment 12 Daniel Reed 2004-06-18 09:58:46 EDT
*** Bug 98752 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schröder 2004-06-23 05:46:14 EDT
Please don't do it this way. Either kbs is ^H in the terminfo entry
of the terminal (i.e. $TERM before you start screen) then this is a
noop, or it is ^? then you won't be able to send ^? anymore. Just
leave kbs alone.
Anyway please show me an application that looks at kbs? If you find
one (which I doubt) it is broken as it should check the stty setting
instead. I think you're trying to fix another problem with that gross
workaround.
Comment 14 David Balažic 2004-06-23 07:00:17 EDT
I have already shown programs that don't work in there is a mismatch
between terminfo/kbs and the actual code sent. You show me a program
that does not work when terminfo matches reality.
Comment 15 David Balažic 2004-06-23 07:16:43 EDT
I already did some test here :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77833#c9
Comment 16 Jason Merrill 2004-06-24 13:29:58 EDT
I still don't see why we can't just use ^? under screen.
Comment 17 David Balažic 2004-07-01 03:39:05 EDT
Because backspace is defined to be ^H under screen since ages. It is
like changing the ASCCI code of 'a' to 0x01. You can do it, and it
will even work on _your_ system, but it will break when coming in
touch with the rest of the world.
Comment 18 Jason Merrill 2004-07-01 17:33:24 EDT
It already breaks when you come into contact with the rest of the
world, because most systems don't have a terminfo entry for screen. 
It seems to me that using ^H for kbs was a thinko at some point in the
distant past and we're all paying the price for it now.

^? has been the erase character on all sensible terminals for decades.
 Doing something different in screen doesn't make any sense.

I don't think that retaining this ancient brain damage is worth the
price of forcing workarounds in many other packages.
Comment 19 David Balažic 2004-08-09 04:09:34 EDT
" because most systems don't have a terminfo entry for screen"
But they have "vt100", which is 90% comaptible ( includig kbs=^H ).

And a lot of existing terminals use ctrl-H.

I really don't see the problem of following the defined standards.
Comment 20 Daniel Reed 2004-08-09 11:17:24 EDT
$TERM is set by the host for the benefit of the client, as explained
below. In the simplest case, it is set by the terminal for the benefit
of ls, pico, etc.

screen is both a client to your terminal and a host to your programs.
screen uses the $TERM set by your terminal (or terminal emulator) to
figure out how to display properly to that terminal, and figure out
the keys your terminal is sending to it. screen then sets $TERM for
its subordinate processes (ls, pico) so they know how to represent
their concept of the visual layout to screen, and how to interpret the
keys screen sends back to them.

gnome-terminal  <-->  screen  <--->  pico
             TERM=gnome    TERM=screen

For example:
 User hits Backspace.
 gnome-terminal sends \177 to screen.
 screen consults terminfo for "gnome", sees that \177 is kbs, and
interprets it as Backspace.
 screen sends ^H to pico.
 pico consults terminfo for "screen", sees that ^H is kbs, and
interprets it as Backspace.
 All is right in the world.

This intermediate translation (between what your terminal is sending
and what the client (pico) is receiving) is essential, as screen
allows you to "detach" and later "reattach" from a different terminal
(which may send different keys). In fact, you can use screen to
"multiplex", where multiple physical terminals can be attached to the
same screen simultaneously, all of which potentially using different keys.

screen defines a standard ^H to pass to subordinate processes, and
guarantees that those processes will always receive ^H to mean
Backspace, even in the face of changes in the physical terminal type.
screen uses ^H because vt100 uses ^H, and screen falls back to setting
$TERM to "vt100" if "screen" is not available.

screen sends ^H to its subordinate processes when it receives a
Backspace, so "infocmp -1 screen | grep kbs" should output:
        kbs=^H,
If it does not, this is a terminfo bug and should be re-filed under
ncurses. In rawhide, terminfo/screen does correctly list ^H.

To the best of my knowledge, gnome-terminal does send \177, so
"infocmp -1 gnome | grep kbs" should display kbs=\177. If it does not,
this is the bug (and should also be filed under ncurses). In rawhide,
terminfo/gnome lists kbs as \177.

If you can list a specific terminal (including its version), version
of screen, and version of ncurses, I can attempt to reproduce the
problem and figure out where the actual miscommunication or
mis-setting is. As of right now, I am unable to reproduce the problem
in today's rawhide versions of gnome-terminal (2.7.3-1), terminfo
(ncurses-5.4-11.fc3), screen (4.0.2-4), and cat (coreutils-5.2.1-19).

You can check your versions of these packages with:
rpm -q --whatprovides `which gnome-terminal` /usr/share/terminfo
`which screen` `which cat`
Comment 21 Daniel Reed 2004-08-09 12:16:58 EDT
gnome-terminal is actually configurable. Under Edit, Current Profile,
Compatibility, Backspace key generates, if it is set to "ASCII DEL" it
will correspond to the terminfo/gnome setting of \177.

If I manually reconfigure gnome-terminal to use ^H instead of ASCII
DEL--without changing terminfo--then run cat and attempt to use
Backspace, I see "^H" appear on the terminal. This happens regardless
of whether I am using screen or not.
Comment 22 Daniel Reed 2004-08-17 17:25:26 EDT
Please reopen if there is a specific combination that does not work.

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