Bug 62671 - Backspace problem in xterm after upgrade to XFree86-4.1.0-15
Backspace problem in xterm after upgrade to XFree86-4.1.0-15
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-03 21:48 EST by Need Real Name
Modified: 2007-03-26 23:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-09 00:33:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-04-03 21:48:41 EST
Description of Problem:
I applied updates to my very vanilla RH 7.1 install (install everything
selected), and after upgrading to XFree86-4.1.0-15, xterm seemed to switch the
erase character from ^? to ^H.  I've spent most of the afternoon trying to
figure out where the problem is, and I can't find it.  I'm not an expert, but I
think the termcap entries look ok...

  xterm|X11 terminal emulator:\
        :tc=xterm-redhat:

and

  xterm-redhat|Red Hat xterm (backspace and delete changed):\
        :kD=\E[3~:kb=\177:tc=xterm-xfree86:

Nevertheless the problem persists.

I can work around the problem in several ways.  For most applications, I can use 
  stty erase ^?
to solve the problem.  This works fine if I'm using an xterm that I've launched
which sources my .profile file.  It is undesireable to put it in .bashrc,
because the scp command sources this file, and output or errors to commands such
as this can cause scp to fail.  In such a case, stty will always fail, because
there is no tty for the program.  So putting stty commands in .bashrc is a bad idea.

So, the above works in all cases, except for the one which is most important to
me: in an xterm launched to execute a program (i.e. xterm -e).  When launched
this way, xterm does not source the .profile, so my stty commands don't run.  As
it happens, I frequently launch my mail program and a vim session this way, so
this breaks backspace for about 80% of what I do on my system.

I found a work-around for this, too; but I'm baffled by WHY it works.  If I set
the resource XTerm.termName to xterm-redhat, the backspace problem disappears. 
However this is undesireable, as it makes my .Xdefaults file unportable.

Furthermore, I fail to understand why using the term type xterm-redhat works but
xterm doesn't, when the termcap entries are (or should be) identical. Does xterm
use terminfo instead?  I know very little about terminfo... Hopefully the
information I've provided will help you find the problem better than I was able to.

I note here also that xterm seems to be compiled against ncurses4, which also
was updated at the same time.  I don't know if that might be the source of the
problem instead...

Version-Release number of selected component (if applicable):
XFree86-4.1.0-15

How Reproducible:


Steps to Reproduce:
1. Install RH 7.1 
2. apply updates
3. watch ^? appear in your xterm (in an editor session or similar) when
backspace is pressed

Actual Results:


Expected Results:
Backspace key should delete a character instead of producing ^?

Additional Information:
Comment 1 Need Real Name 2002-04-03 23:30:52 EST
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.
Comment 2 Need Real Name 2002-04-03 23:41:55 EST
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.  ;-)
Comment 3 Mike A. Harris 2002-04-08 18:52:05 EDT
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.
Comment 4 Need Real Name 2002-04-08 22:45:13 EDT
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.
Comment 5 Need Real Name 2002-04-09 00:14:53 EDT
This bug also exists in RH 7.2's XFree86-4.1.0-3 package.
Comment 6 Need Real Name 2002-04-09 00:20:06 EDT
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.
Comment 7 Need Real Name 2002-04-09 00:32:57 EDT
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@redhat.com
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.
Comment 8 Mike A. Harris 2002-04-09 08:28:44 EDT
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.


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