Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 6358 - Xterm sets erase wrongly on tty
Summary: Xterm sets erase wrongly on tty
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xterm-color
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL: http://home.worldonline.dk/~ehcorry/l...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-25 23:56 UTC by erik
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-01-18 20:12:50 UTC


Attachments (Terms of Use)

Description erik 1999-10-25 23:56:51 UTC
Xterm reads its termcap entry in order to set stty erase to
the correct value.  The correct value is 'stty erase ^H'
since that is what xterm by default produces for a BackSpace
keysym, and that is what the termcap/terminfo entries say
(kb/kbs).  Unfortunately, xterm reads the wrong termcap
entry (kD equivalent to terminfo entry kdch1) and sets the
tty erase character to ^?.  This means programs that don't
autocompensate (cat, ftp, anything not linked to readline)
get confused and you can't delete with the expected button.
And programs that use readline lose the ability to delete to
the right (delete the character under the cursor) which is
the real meaning of kdch1 as per the terminfo docs (and what
any new user would expect).  This could otherwise be
achieved with a line
DEL: delete-char
in /etc/inputrc.

I linked to a patch that fixes it.  According to the xterm
FAQ on http://www.clark.net/pub/dickey/xterm/xterm.faq.html
this is the way it was originally, don't know who broke it,
but they didn't read the kD entry on man 5 termcap first.

An additional problem is that the xterm termcap entry would
be over 1023 characters, so it is truncated when converting
from terminfo.  This means that the kD (kdch1) info is
missing (doubly ironic when xterm tries wrongly to read it
to set the tty), so xterm does not know how to send the data
from the Delete key.  Xterm sends ^?, while apps that read
terminfo will expect ^[[3~ like on the linux console.  This
is a smaller problem since the line above will fix things
for readline apps that make up the majority of apps that
would know what to do with the delete key anyway.

Comment 1 erik 1999-10-26 09:23:59 UTC
I forgot to mention, you have to reverse the 'aaargh' patch to the
latest termcap (2.0.8-18) before xterm can see the termcap entry at
all.  The aaargh patch breaks the API.  Probably should be redone so
it works the old way unless the TERMCAP entry is overlong.  Not sure
what it was supposed to fix, anyway.

Comment 2 Bill Nottingham 1999-10-26 15:11:59 UTC
It's a security fix; it will most likely *not* be reverted.

Comment 3 Preston Brown 2000-01-18 20:12:59 UTC
xterm terminfo stuff fixed for next release.


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