Bug 119809

Note that I still get this behavior after running "setenforce 0", so I
doubt this problem is related to SELinux.

Red Hat ships xterm stock, with the possible exception of the
occasional security bugfix.  If there is a bug in xterm resource
handling, it is most likely an upstream xterm resource handling
bug.

This seems to be more of a technical support request than a
conclusive bug report, which bugzilla is not intended for.

I recommend discussing this issue on Xorg, or XFree86 mailing
lists, or reporting this issue directly to the upstream xterm
author, so that a more conclusive assessment of the problem can
be made to determine wether it is a real bug in xterm, something
else, or wether it is just misconfiguration.

If there is a bug present, then hopefully it will be addressed in a
future upstream xterm release.

If you report your upstream bug report URL here, I will track the
issue upstream for periodic review in the future.  If it is
determined to be a bug, I will review the upstream fix for
consideration in future releases.

Thanks in advance.


Setting bug status to "UPSTREAM"

It would be nice if "UPSTREAM" weren't symlinked to /dev/null.

fwiw, it works when I try his example.  It looks specific
enough that I'm not sure what resource conflicts it might
have.  With xterm, he can always look at the control/middle
mouse menu, which would show if "Enable Alternate Screen
Switching" is enabled (that's the same as the resource
setting).

Well, I figured it out: the "xterms" terminal definition is broken.

Terminals where TiteInhibit works:

xterm-basic
xterm-new
xterm-xfree86

Terminals where TiteInhibit doesn't work:

xterm
xterm-color
xterm-old
xterm-sun
xterms

I've reopened this bug and changed the component to ncurses.

I see this problem with ncurses-5.4-4.1.

Not really.  You're observing differences between terminfo
entries which are a preference, not a requirement.

Eh?

$ rpm -q fedora-release
fedora-release-1.91-6

$ infocmp xterm xterm-new
comparing xterm to xterm-new.
    comparing booleans.
    comparing numbers.
    comparing strings.
        kbs: '\177', '^H'.
        kdch1: '\E[3~', '\177'.

The only thing TiteInhibit does is to cause xterm to remove the ti and
te termcap entries (I've looked at the source to verify that).  The
"xterm" and "xterm-new" definitions don't differ in that aspect.

Why, then, is xterm incapable of disabling the screen switching when
my term is "xterm" but not when my term is "xterm-new"?

I doubt that you looked at the source, since it in fact does more
than remove ti/te.  Perhaps you're looking at an old source.
This is current: http://invisible-island.net/xterm/ (even Redhat's
package is recent enough, since I made these changes several years
ago).  See http://invisible-island.net/xterm/xterm.log.html#xterm_90

I'm also looking at the rpm's that come with fedora-release-1.91-6:
xterm-179-6.EL.src.rpm and ncurses-5.4-4.1.src.rpm, which show
the actual problem.  To work around some bugs in gnome-terminal
they've packaged ncurses with "xterm" aliased to "gnome-rh80".
The "xterm-new" entry is still (as I wrote it) "xterm-xfree86".
The former uses the 47 private-mode sequence, while the latter
uses the 1049 private-mode sequence (see rmcup/smcup).  Since
xterm is linked with terminfo (ncurses), changes to $TERMCAP
have no effect.  The 1049 sequence is recognized by xterm, but
(only partly) by the other emulators.  Having reviewed
gnome-terminal recently, I'm certain that it doesn't do this.

Perhaps you have a $HOME/.terminfo which is confusing you -
and xterm is using the system's copy of it rather than your
private copy.  If you simply type "infocmp xterm", it would
also show the path where it finds the entry.

The essential information about this stuff is in my ncurses and
xterm faqs.

I should cease to comment on bug reports very early in the morning.
:(

You're right; I see now from my command history that I only grep'ed
main*, instead of all of the source files.

And I screwed up the infocmp command by running it on the wrong
machine.  Here's what I should have found:

$ infocmp xterm gnome-rh90
comparing xterm to gnome-rh90.
    comparing booleans.
    comparing numbers.
    comparing strings.

$ infocmp xterm-new xterm-xfree86
comparing xterm-new to xterm-xfree86.
    comparing booleans.
    comparing numbers.
    comparing strings.

While I can empathize with Red Hat's wanting to work around bugs in
gnome-terminal, secretly aliasing "xterm" to something else
("gnome-rh90", for FC2 test2) is not the way to do it.  If
gnome-terminal chokes when TERM is "xterm", then people should be
setting TERM to something that gnome-terminal *doesn't* choke on.

Well, I wouldn't say "secretly".  The real problem is that
the people making the fixes don't seem to get at the real
issue - whether because they haven't time, or background
I can't say.  Looking at the long list of bugs for gnome-terminal,
I'd say the former is a strong factor.

I dunno; it was pretty "secret" to me--it wasn't mentioned in the
release notes for FC2 test2, and it took a non-trivial amount of
digging to figure out what was going on.

While I still think changing the definition of "xterm" is wrong, if
FC2 final is shipped with xterm aliased to gnome-rh90, that should
DEFINITELY be mentioned in the release notes.

(If nothing else, this will probably be the motivation I need to make
my login scripts smart enough to find the "best" TERM setting for the
system in question.)

In fedora core 3, the xterm terminfo is really xterm, for gnome-terminal,    
TERM=gnome is appropriate (and works). It would be nice if you could try to  
reproduce your problem with the right TERM settings in FC3, it should, in  
theory, work. 

I have not tried your example in FEDORA CORE test2
but it works fine in FEDORA CORE 4.

That is why I am not able to say where 'a possible bug' was.
I will close this 'issue': Fixed in current release.

(Launch at the command prompt: nohupx xterm &
 Press keys: 'Ctrl' + 'mouse-button-2' -> Enable Alternate Screen Switching==NO'
)