Bug 119809 - cannot disable "alternate screen switching" (TiteInhibit)?
cannot disable "alternate screen switching" (TiteInhibit)?
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
Depends On:
  Show dependency treegraph
Reported: 2004-04-02 03:13 EST by James Ralston
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: ncurses 5.5 Release 10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-12 11:15:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Ralston 2004-04-02 03:13:26 EST



For ages, I have had this Xresource set:

    XTerm.VT100.TiteInhibit: true

This is because I hate "alternate screen switching" with a high
flaming passion.  (I call it the "erase all of the useful things I was
just looking at" feature.)

For FC2 test2, xterm appears to ignore this resource; it always
performs screen switching.

Is there some other (preferred) way to disable "alternate screen
switching" now?  Or is this just a bug?
Comment 1 James Ralston 2004-04-02 03:14:36 EST
Note that I still get this behavior after running "setenforce 0", so I
doubt this problem is related to SELinux.
Comment 2 Mike A. Harris 2004-04-02 15:21:21 EST
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

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"
Comment 3 Thomas E. Dickey 2004-04-05 16:16:01 EDT
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
Comment 4 James Ralston 2004-04-06 17:27:22 EDT
Well, I figured it out: the "xterms" terminal definition is broken.

Terminals where TiteInhibit works:


Terminals where TiteInhibit doesn't work:


I've reopened this bug and changed the component to ncurses.
Comment 5 James Ralston 2004-04-06 18:40:00 EDT
I see this problem with ncurses-5.4-4.1.
Comment 6 Thomas E. Dickey 2004-04-07 06:52:09 EDT
Not really.  You're observing differences between terminfo
entries which are a preference, not a requirement.
Comment 7 James Ralston 2004-04-09 07:22:07 EDT

$ rpm -q fedora-release

$ 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"?
Comment 8 Thomas E. Dickey 2004-04-09 18:44:01 EDT
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.
Comment 9 James Ralston 2004-04-09 21:38:04 EDT
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.
Comment 10 Thomas E. Dickey 2004-04-10 06:54:57 EDT
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.
Comment 11 James Ralston 2004-04-12 05:23:57 EDT
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.)
Comment 13 Petr Rockai 2005-02-18 08:33:06 EST
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. 
Comment 14 Petr Raszyk 2006-01-12 11:15:27 EST
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'

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