Bug 6358

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.