Bug 62671

Possible additional useful info:

I ran xterm through strace with and without the XTerm.termName resource set.
Xterm appears to be using the terminfo database entries.  What's really
interesting is what entries get opened when the resource is set and not set...

With the XTerm.termName resource to xterm-redhat, xterm only open(2)'s the
terminfo file for xterm-redhat (see end of output):

[bunch of stuff snipped out]
open("/usr/X11R6/lib/X11/app-defaults/XTerm", O_RDONLY) = 4
open("/dev/tty", O_RDWR)                = 4
open("/dev/ptmx", O_RDWR)               = 4
open("/usr/X11R6/lib/X11/locale/compose.dir", O_RDONLY) = 5
open("/usr/X11R6/lib/X11/locale/iso8859-1/Compose", O_RDONLY) = 5
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 6
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 6
open("/usr/share/terminfo/x/xterm-redhat", O_RDONLY) = 5


HOWEVER, with the resource UNSET, it opens numerous entries:

open("/usr/X11R6/lib/X11/app-defaults/XTerm", O_RDONLY) = 4
open("/dev/tty", O_RDWR)                = 4
open("/dev/ptmx", O_RDWR)               = 4
open("/usr/X11R6/lib/X11/locale/compose.dir", O_RDONLY) = 5
open("/usr/X11R6/lib/X11/locale/iso8859-1/Compose", O_RDONLY) = 5
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 6
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 6
open("/usr/share/terminfo/x/xterm", O_RDONLY) = 5
open("/usr/share/terminfo/x/xterm", O_RDONLY) = 5
open("/usr/share/terminfo/v/vt102", O_RDONLY) = 5
open("/usr/share/terminfo/v/vt100", O_RDONLY) = 5
open("/usr/share/terminfo/a/ansi", O_RDONLY) = 5
open("/usr/share/terminfo/d/dumb", O_RDONLY) = 5


I'm guessing it's getting the value for kbs from one of the subsequent terminfo
entries.  However, according to the comments in /etc/termcap:

# System administrators can change the default entry for xterm instances
# by adding a similar line to /usr/X11/lib/X11/app-defaults/XTerm.  In either
# case, xterm will detect and reject an invalid terminal type, falling back
# to the default of xterm.

Indeed, if that resource is not set, it makes no sense, IMO, for xterm to check
any other entry besides that of xterm.

I followed the above line of reason logically and concluded that I should try
setting the XTerm.termName resource specifically to xterm.  Sure enough, that
fixed the problem, and now xterm only opens the terminfo entry for xterm:

open("/usr/X11R6/lib/X11/app-defaults/XTerm", O_RDONLY) = 4
open("/dev/tty", O_RDWR)                = 4
open("/dev/ptmx", O_RDWR)               = 4
open("/usr/X11R6/lib/X11/locale/compose.dir", O_RDONLY) = 5
open("/usr/X11R6/lib/X11/locale/iso8859-1/Compose", O_RDONLY) = 5
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 6
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 6
open("/usr/share/terminfo/x/xterm", O_RDONLY) = 5


I think the right fix for this problem is to make sure xterm only opens the
terminfo entry for xterm (at least, if it exists).  However it may be that the X
development team did this for reasons that aren't obvious to me...

At the very least, an entry should be added to
/usr/X11R6/lib/X11/app-defaults/XTerm like so:

XTerm.termName:    xterm

Note also that I can not easily verify what the OLD behavior (of the 4.0.3 X
package) was, as I have no un-upgraded RH 7.1 systems to examine it on.  And,
while I'll admit some curiosity, downgrading is WAY too tedious for me to bother
with, given that I've solved my problem.  ;-)

I do not have this problem when running any release of X with xterm.
The proper term type is xterm.

You've indicated you've solved the problem as a local config issue so I'm
closing the bug out.

THIS IS NOT A LOCAL CONFIG ISSUE.  YOU NEED TO FIX THIS PROBLEM.  Just because
you can work around the problem with a local config change does not mean it is a
local config problem.  Jeezus.

Also, I never said that TERM was set to the wrong value.  Please read what I
wrote.  TERM *IS* set to xterm.  However, xterm reads the terminfo entries for
other term types, DESPITE that.  I gave you the strace output to prove it.

Note also that I said I was having the problem when I exec'd a program from
xterm's command line, i.e.

  xterm -e vi

Did you even try this?  I can't imagine you possibly could have... I've tried it
on 4 different RH 7.1 systems with the XFree86-4.1.0-15 RPM update applied, and
they all exhibited this behavior.

Try this:

1. Make sure you do *NOT* have XTerm.termName set to xterm in your .Xdefaults
file.  Red Hat does not set this in the /usr/X11R6/lib/X11/app-defaults/XTerm
file provided with XFree86-4.1.0-15 RPM, and virtually no one will know about
this resource, and new users DEFINITELY will not know about it.  (OTOH, they
probably won't know they can run xterm -e progname either...  But then it's a
lot easier to figure that out than it is to fix the backspace problem.)

2. Make sure you are running with the default .bashrc and .bash_profile that is
provided with Red Hat.  If need be, the easiest way to do this is create a new
user.  If you are using a customized .bashrc or .bash_profile, it may contain
commands that work around this problem.  Typical users will not know how to work
around the problem, and new users DEFINITELY will not know how to work around
the problem.

3. Log in at the text console.

4. run startx to start the X Window System.

5. run xterm -e vi

6. enter insert mode, and type characters.  Now press backspace.  You will see
^? instead of backspacing.  This is WRONG!

7. hit escape to exit out of insert mode.

8. type :! echo $TERM to see the value of $TERM.  Note that it is set correctly
to xterm

9. type :! stty -a and examine the output, noting the value for erase.  It will
be ^H!  THIS IS WRONG!

The reason erase is not set properly is because xterm reads the terminfo entries
for first xterm, then xterm a second time (which is just bizarre), then vt102,
then vt100, then ansi, then dumb.  While the skb setting in the entry for xterm
is correctly set to ^? (\177), in the rest it is set to ^H.  Under normal
circumstances, when you start an xterm, it execs bash, which fixes the problem
SO LONG AS THE USER DOES NOT MODIFY THE DEFAULT BEHAVIOR.

The REASON it fixes the problem is as follows:  Since bash is running in an
interractive session, it sources /etc/bashrc which does this:

  stty erase `tput kbs`

This uses the current value of $TERM to get the correct setting for kbs from the
terminfo database, and resets the backspace key to the correct '^?' instead of
what xterm sets by default. However, when xterm is run with the -e option, xterm
starts the program directly without first starting a shell, so /etc/bashrc is
never sourced.

Note further that if the user modifies their .bashrc so that it does not source
/etc/bashrc, they will also encounter this problem, and will not have any idea why.

I already worked out the cause and the solution of the problem for you, and I
gave you the solution to the problem in my previous notes.  Please see my
comments immediately prior to yours.  Unfortunately I can not fix the problem
for you, you're going to have to do that yourself.

This bug also exists in RH 7.2's XFree86-4.1.0-3 package.

This bug also (unsurprisingly) exists in the 4.1.0-15 update for 7.2

I've tested 7 machines, and they all exhibit the problem.  Hopefully that will
convince you it's not a local config problem.  3 of the seven are brand new
installs, which I have done absolutely no configuration or customizing to, other
than to install the updates on two of them.

I have notified the XFree86 team of this bug to possibly identify whether it's
an upstream source problem, or Red Hat specific.  I've CC'd mharris
on my correspondence.  I have no way to test their pristine binary distributions
that wouldn't take hours worth of work (removing RPMs, downloading and
installing binaries, performing tests, removing the binaries, re-installing
RPMs) that I really have no need to spend.  I've already spent about 10 hours of
my own time on identifying and resolving this problem, which is way more than I
wanted to.  I figure if I can get you guys to fix it in future releases, it'll
make my life easier by preventing me from having to do it on every system I
install.  Since I stopped paying for your distro after 6.1, I figure it's a fair
trade (my QA time for your distro).

Have a nice day.

You seem to have a severe attitude problem.  I am not apt to even listen
to you if you're going to go into a huge negative flame war in bugzilla.

Lets consider some facts here.  I have RHL 7.1 installed, and I've got
XFree86 4.1.0-3 installed on my system as well:

pts/12 mharris@zod:~$ cat /etc/redhat-release
Red Hat Linux release 7.1 (Seawolf)
pts/12 mharris@zod:~$ rpm -q XFree86
XFree86-4.1.0-3

I am able to run xterm and run applications in xterm with NO PROBLEMS
WHATSOEVER.  Backspace AND delete *BOTH* work FLAWLESSLY for me.  I am
using default configurations of things and have NOT modified termcap,
terminfo, or any X resources files from the default installation.

I will say one thing however.  During my maintenance of XFree86, I have
made VERY few numbers of changes to xterm, some user requested enhancements,
and others have been to try and fix bugs reported.  Most bugs reported,
have been to fix problems caused by the user requested enhancements.

As such - we OFFICIALLY do not and WILL NOT make any further changes
to xterm beyond what is shipped in XFree86.  If users want enhancements
made, they can make them themself post-installation because it has shown
that when we make the enhancements, we also get the flames.  xterm is NOT
an officially supported terminal program in Red Hat Linux.  Our officially
supported terminals are gnome-terminal and konsole.

People often claim they have found a bug in xterm or it's configuration,
and they often supply a fix.  When using their given "fix" what generally
occurs is that existing behaviour that 10000 other users expect now breaks,
and THOSE users become equally pissed off about it.

Since there is no way to consistently please everyone and have a default
configuration that does all things to all people, and since I am able to
run xterm and have backspace and delete work just fine, and also since
I simply refuse to be talked down to and flamed in a bug report like this
I am declaring this issue officially CLOSED.  It WORKSFORME.