Bug 1103320 - screen running with TERM=screen.xterm is broken
screen running with TERM=screen.xterm is broken
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Other
Leap 15.0
x86-64 All
: P5 - None : Major (vote)
: ---
Assigned To: Michael Schröder
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-01 03:11 UTC by Bernhard Wiedemann
Modified: 2019-11-23 23:37 UTC (History)
6 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Wiedemann 2018-08-01 03:11:43 UTC
After upgrading from 42.3 to 15.0
I found that bug 940459 was re-introduced in 15.0 when the ncurses changes in bug 935736 were reverted by Werner via https://build.opensuse.org/request/show/497888

People say "use tmux instead" and indeed, tmux uses TERM=screen
in its virtual windows, which works fine.

But screen uses TERM=screen.xterm which breaks alt-leftarrow (and ctrl-leftarrow) to skip a word in bash prompt - even locally.

and over ssh to a SLE-12 it is a total mess anyway (see old bugs).

Also, you cannot override it using a 'term screen' in .screenrc
or with ^A:term screen 
or with screen -T screen
which is a bug in itself because documentation clearly says that this should work.
Comment 1 Bernhard Wiedemann 2018-08-01 03:17:30 UTC
actually, screen -T xterm-new
does work, so you can set the terminal to certain values, but not to "screen"
which is what I would need.
Comment 2 Michael Schröder 2018-08-01 09:39:54 UTC
So where's the bug I should fix?

Anyway, you could try to start screen with the '-a' option.
Comment 3 Michael Schröder 2018-08-01 09:41:57 UTC
Btw, why would alt-leftarrow work with TERM=screen and not with TERM=screen.xterm? Doesn't that mean that the screen.xterm entry is bad, which is not a screen bug but a ncurses bug?
Comment 4 Bernhard Wiedemann 2018-08-01 12:34:10 UTC
Yes, screen -a helps to get TERM=screen again,
including working alt-left in bash
and working remote ssh sessions to older Linuxes.

man screen says
       -a   include all capabilities (with some minor exceptions) in each win-
            dow's termcap, even if screen must redraw parts of the display  in
            order to implement a function.

so is it not default, because there might be expensive features?
Or are there other reasons?

and what is the TERM=screen.xterm supposed to do?

I think, screen.konsole was similarly broken.

/usr/share/terminfo/s/screen.xterm comes from the
terminfo-screen rpm from the ncurses srpm.

But OTOH it is still bad to set TERM=screen.xterm by default
when my remote machine does not have the file.
Comment 5 Michael Schröder 2018-08-01 15:48:31 UTC
"screen.xterm" is supposed to be a termcap info that is a better fit for "xterm" than the "screen" entry. I don't think it matters much for xterm, so I don't see why we have it.

But let's say you have a very dumb terminal 'foo' and TERM=foo. You then start screen. With term="screen" the processes in screen will think that all fancy capabilities are present, and screen must try to emulate/ignore stuff. With TERM=screen.foo you can have a dumbed down entry that only includes the stuff that works.

With '-a' you tell screen not to do this and just go with "screen".

And you don't know what remote machines have for *all* entries.

But, as said, I don't know why there's a screen.xterm entry. Did you do a comparison with the screen entry? (Use the 'infocmp -d' command)
Comment 6 Bernhard Wiedemann 2018-08-02 09:21:09 UTC
terminfo of screen.xterm seems to be more similar to xterm than to screen

> infocmp -d screen.xterm xterm
comparing screen.xterm to xterm.
    comparing booleans.
        bce: F:T.
        bw: T:F.
    comparing numbers.
    comparing strings.
        invis: NULL, '\E[8m'.
        kIC: NULL, '\E[2;2~'.
        kNXT: NULL, '\E[6;2~'.
        kPRV: NULL, '\E[5;2~'.
        kend: '\E[4~', '\EOF'.
        kfnd: NULL, '\E[1~'.
        khome: '\E[1~', '\EOH'.
        kmous: '\E[M', '\E[<'.
        kslt: NULL, '\E[4~'.
        ritm: NULL, '\E[23m'.
        sgr: '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m', '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m'.
        sitm: NULL, '\E[3m'.




comparing screen.xterm to screen.
    comparing booleans.
	bw: T:F.
	mc5i: T:F.
	npc: T:F.
    comparing numbers.
    comparing strings.
	acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', '++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'.
	clear: '\E[H\E[2J', '\E[H\E[J'.
	cnorm: '\E[?12l\E[?25h', '\E[34h\E[?25h'.
	cuu1: '\E[A', '\EM'.
	cvvis: '\E[?12;25h', '\E[34l'.
	ech: '\E[%p1%dX', NULL.
	enacs: NULL, '\E(B\E)0'.
	flash: '\E[?5h$<100/>\E[?5l', '\Eg'.
	is2: '\E[!p\E[?3;4l\E[4l\E>', '\E)0'.
	kDC: '\E[3;2~', NULL.
	kEND: '\E[1;2F', NULL.
	kHOM: '\E[1;2H', NULL.
	kLFT: '\E[1;2D', NULL.
	kRIT: '\E[1;2C', NULL.
	kb2: '\EOE', NULL.
	kent: '\EOM', NULL.
	kf13: '\E[1;2P', NULL.
	kf14: '\E[1;2Q', NULL.
...
	kf62: '\E[1;4Q', NULL.
	kf63: '\E[1;4R', NULL.
	kind: '\E[1;2B', NULL.
	kri: '\E[1;2A', NULL.
	mc0: '\E[i', NULL.
	mc4: '\E[4i', NULL.
	mc5: '\E[5i', NULL.
	nel: NULL, '\EE'.
	rep: '%p1%c\E[%p2%{1}%-%db', NULL.
	rin: '\E[%p1%dT', NULL.
	rmacs: '\E(B', '^O'.
	rmam: '\E[?7l', NULL.
	rmcup: '\E[?1049l\E[23;0;0t', '\E[?1049l'.
	rmm: '\E[?1034l', NULL.
	rmso: '\E[27m', '\E[23m'.
	rs1: '\Ec', NULL.
	rs2: '\E[!p\E[?3;4l\E[4l\E>', '\Ec\E[?1000l\E[?25h'.
	setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
	setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
	sgr: '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m', '\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;'.
	sgr0: '\E(B\E[m', '\E[m\017'.
	smacs: '\E(0', '^N'.
	smam: '\E[?7h', NULL.
	smcup: '\E[?1049h\E[22;0;0t', '\E[?1049h'.
	smm: '\E[?1034h', NULL.
	smso: '\E[7m', '\E[3m'.
	u6: '\E[%i%d;%dR', NULL.
	u7: '\E[6n', NULL.
	u8: '\E[?%[;0123456789]c', NULL.
	u9: '\E[c', NULL.


I guess, for now I'll have to make 'screen -a' my new default
(I'm attaching from multiple machines anyway that could have different terminals)
Comment 7 Bernhard Wiedemann 2018-08-02 13:11:20 UTC
bug 1095661 has updates for bash/libreadline to fix ctrl-arrow in screen
Comment 8 Michael Schröder 2018-08-02 14:53:17 UTC
Wow, I wonder how that screen.xterm entry got created. It's insane that there are so many differences.
Comment 9 Dr. Werner Fink 2018-08-03 07:12:09 UTC
(In reply to Michael Schröder from comment #8)
> Wow, I wonder how that screen.xterm entry got created. It's insane that
> there are so many differences.

from patched ncurses-6.1/misc/terminfo.src I see

  #:screen.xterm|screen for modern xterm,
  #:     use=screen.xterm-new,
 +screen.xterm|screen customized for modern xterm,
 +       bce@, bw,
 +       invis@, kIC@, kNXT@, kPRV@, meml@, memu@,
 +       sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|
 +           %t;7%;%?%p4%t;5%;%?%p5%t;2%;m,
 +       E3@, use=screen+italics, use=screen+fkeys,
 +       use=xterm+x11mouse, use=xterm-suse,

with standard xterm-suse used for xterm entry

 +# For SuSE Linux: Werner Fink <werner@suse.de>
 +# Note that the modern xterm does not use escape sequences
 +# for the numbers on the numpad keys in case of switched
 +# into application mode and with numlock enabled.
 +# To test this, use `tput smkx' and `Ctrl-V + key stroke'
 +xterm-suse|xterm terminal emulator (X.Org X11R7.7 Window System with SuSE LINUX), 
 +       kbs=\177, kdch1=\E[3~,
 +       kDIV=\EOo, kMUL=\EOj, kMIN=\EOm, kPLS=\EOk,
 +       kfnd=\E[1~, kslt=\E[4~,
 +       use=xterm-new,
 +
  # This is xterm for ncurses.
  xterm|xterm terminal emulator (X Window System),
 +       use=xterm-suse,

it should be noted that screen.xterm exists only because the program screen uses screen.xterm (see https://bugzilla.opensuse.org/show_bug.cgi?id=935736 ) and I would be happy if screen would NOT use any screen.* entry at all as this cause trouble e.g. on ssh from local system to an other system which does not know at all about those screen.* entries (https://bugzilla.opensuse.org/show_bug.cgi?id=940459 ).

Please be aware that the reintroducing the entry screen.xterm was done because with ncurses patch 20150627

 >  + comment-out "screen.xterm" entry, and inherit screen.xterm-256color
 >    from xterm-new (report by Richard Birkett) -TD

with the entry added from the discussion on the mailing list.  If you have an better
entry then let me know or DISABLE screen.* entries
Comment 10 Geoff Kuenning 2018-11-10 09:06:34 UTC
Any solution that boils down to "invoke screen differently" is incorrect.  If I am running on a terminal that has capabilities XYZ, then invoking screen should not break those capabilities.

Any solution that boils down to "use a different program" is also incorrect.

That's especially true when the terminal in question is xterm.

I agree that it's unwise of the screen developers to expect a screen-specific termcap entry; there are too many systems that won't have it.  And in my case I'm spawning screen from xterm on a local OpenSuSE system, so even when everything is "as it should be" from the developers' standpoint, it's still broken.  Not Good.

The easy short-term solution would be to modify screen to set TERM=vt100.  That might not produce the most efficient escape sequences, but it would work.  And at modern CPU and network speeds, I doubt it would create any performance difference.  (To be fair, I detest colorization so maybe that solution wouldn't work for people who like rainbows, but I bet there's another setting that works even for them.)
Comment 11 Bernhard Wiedemann 2018-11-10 10:45:31 UTC
Geoff, 
the problem here is that the terminfo-screen
contains a screen.xterm file that is incorrect, but used by screen
because it exists.

So just uninstalling just that one package avoided this bug for me.
And zypper al terminfo-screen
to ensure that it does not get installed again by mistake.

But as a proper solution we should fix or drop those files.
Comment 12 Dr. Werner Fink 2018-11-12 14:13:02 UTC
(In reply to Bernhard Wiedemann from comment #11)
> Geoff, 
> the problem here is that the terminfo-screen
> contains a screen.xterm file that is incorrect, but used by screen
> because it exists.
> 
> So just uninstalling just that one package avoided this bug for me.
> And zypper al terminfo-screen
> to ensure that it does not get installed again by mistake.
> 
> But as a proper solution we should fix or drop those files.

To drop this files would cause an other bug, sorry but I do not agree here as if we do this all the time there will be never ever any progress.

Beside this for screen.xterm I'm open for suggested fixes and changes ... from the entry for screen.xterm-new I see:

# Notes:
# (a)   screen does not support invis.
# (b)   screen's implementation of bw is incorrect according to tack.
# (c)   screen appears to hardcode the strings for khome/kend, making it
#       necessary to override the "use=" clause's values (screen+fkeys).
# (d)   screen sets $TERMCAP to a termcap-formatted copy of the 'screen' entry,
#       which is NOT the same as the terminfo screen.<term>.
# (e)   when screen finds one of these customized entries, it sets $TERM to
#       match.  Hence, no "screen.xterm" entry is provided, since that would
#       create heartburn for people running remote xterm's.
# (f)   screen does not support rep.
#
#       xterm (-xfree86 or -r6) does not normally support kIC, kNXT and kPRV
#       since the default translations override the built-in keycode
#       translation.  They are suppressed here to show what is tested by tack.
screen.xterm-xfree86|screen.xterm-new|screen customized for modern xterm,
        bce@, bw,
        invis@, kIC@, kNXT@, kPRV@, meml@, memu@, rep@,
        sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|
            %t;7%;%?%p4%t;5%;%?%p5%t;2%;m,
        E3@, use=screen+italics, use=screen+fkeys,
        use=xterm+x11mouse, use=xterm-new,

From my patch I see

+screen.xterm|screen customized for modern xterm,
+       bce@, bw,
+       invis@, kIC@, kNXT@, kPRV@, meml@, memu@,
+       sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|
+           %t;7%;%?%p4%t;5%;%?%p5%t;2%;m,
+       E3@, use=screen+italics, use=screen+fkeys,
+       use=xterm+x11mouse, use=xterm-suse,

the main difference is `rep@' which removes the rep feature of xterm for screen
Comment 13 Bernhard Wiedemann 2018-11-16 16:29:55 UTC
I do not know anything about terminfos, but I need working cursor keys in my ssh sessions within screen. Fixes are welcome.
Comment 14 Dr. Werner Fink 2018-11-20 14:51:08 UTC
(In reply to Bernhard Wiedemann from comment #13)
> I do not know anything about terminfos, but I need working cursor keys in my
> ssh sessions within screen. Fixes are welcome.

Try Tumbleweed with latest libreadline7:

 * Fri Sep 28 2018 Dr. Werner Fink <werner@suse.de>
 - Rework patch readline-7.0-screen.patch

with this inputrc handles TERM=screen.xterm as TERM=xterm
Comment 15 Michael Schröder 2018-11-21 10:41:12 UTC
But screen does not emulate xterm. It emulates screen.

Can we please drop that stupid screen.xterm entry. It completely messes up everything and it's also somewhat conflicting with screen's goal to emulate a fixed terminal.
Comment 16 Dr. Werner Fink 2018-11-21 10:52:47 UTC
(In reply to Michael Schröder from comment #15)
> But screen does not emulate xterm. It emulates screen.
> 
> Can we please drop that stupid screen.xterm entry. It completely messes up
> everything and it's also somewhat conflicting with screen's goal to emulate
> a fixed terminal.

Aha ... that's interesting as the `screen.<TERM>' feature is implemented and used by screen its self.  I've no problem to disable the screen.xterm entry if screen does not trow a message about missing screen.xterm entry as well as it is safe to use the `rep' feature of modern XTerm.

Beside this: no one is enforced to install terminfo-screen
Comment 17 Michael Schröder 2018-11-21 12:02:59 UTC
I think the screen.$TERM feature is pretty much a misfeature. I can explain a bit about the history: terminal emulators like screen have a bit of a problem when it comes to which features to "announce" (i.e. which features are in the terminfo  entry). An example is the number of supported colors. Screen can announce that it supports 256 colors, but then it needs to do some crude mapping if you attach with a terminal that only supports 16 colors. So it is somewhat conservative about the entries that are in the "screen" terminal entry. 

Thus the idea was to have "specialized" terminal entries that announce capabilities that are tailored to the terminal you use. That somewhat works but you'll then run into the same problem if you reattach with some other terminal.

So I'd suggest to just drop that entry.

(Screen neither uses nor announces rep, so that can't be a problem.)
Comment 18 Swamp Workflow Management 2018-11-21 12:10:07 UTC
This is an autogenerated message for OBS integration:
This bug (1103320) was mentioned in
https://build.opensuse.org/request/show/650614 Factory / ncurses
Comment 20 Geoff Kuenning 2018-11-24 07:51:23 UTC
(In reply to Dr. Werner Fink from comment #16)

> Beside this: no one is enforced to install terminfo-screen

Werner is of course correct.  But OpenSuSE offers tens of thousands of packages.  I'm not complaining about that (it's one of the reasons I love the distro--"zypper se | wc -l" just gave me 78411!), but it means that the average user isn't going to know the effect of a given package.  My usual default is "install everything that looks vaguely interesting because someday I might need it and it's hand to have it already there".  I don't know whether terminfo-screen is in the defaults for any of the patterns, but under the circumstances I agree that if it's hard to fix, it's probably better to at least find some way to discourage people from installing it.

(I've removed it from my systems and am happier now.  Danke, Werner!)
Comment 21 Swamp Workflow Management 2018-11-26 11:20:07 UTC
This is an autogenerated message for OBS integration:
This bug (1103320) was mentioned in
https://build.opensuse.org/request/show/651982 Factory / ncurses
Comment 22 Swamp Workflow Management 2018-12-07 11:16:15 UTC
SUSE-SU-2018:4000-1: An update that solves one vulnerability and has one errata is now available.

Category: security (important)
Bug References: 1103320,1115929
CVE References: CVE-2018-19211
Sources used:
SUSE Linux Enterprise Module for Legacy Software 15 (src):    ncurses-6.1-5.3.1
SUSE Linux Enterprise Module for Development Tools 15 (src):    ncurses-6.1-5.3.1
SUSE Linux Enterprise Module for Basesystem 15 (src):    ncurses-6.1-5.3.1
Comment 23 Swamp Workflow Management 2018-12-08 14:14:30 UTC
openSUSE-SU-2018:4055-1: An update that solves one vulnerability and has one errata is now available.

Category: security (important)
Bug References: 1103320,1115929
CVE References: CVE-2018-19211
Sources used:
openSUSE Leap 15.0 (src):    ncurses-6.1-lp150.4.3.1
Comment 24 Dr. Werner Fink 2018-12-10 12:31:59 UTC
Should be fixed
Comment 25 Michael Schröder 2018-12-10 12:48:00 UTC
Thanks Werner!
Comment 27 Swamp Workflow Management 2019-11-18 20:15:10 UTC
SUSE-SU-2019:2997-1: An update that solves two vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1103320,1154036,1154037
CVE References: CVE-2019-17594,CVE-2019-17595
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Legacy Software 15-SP1 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Legacy Software 15 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Development Tools 15-SP1 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Development Tools 15 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    ncurses-6.1-5.6.2
SUSE Linux Enterprise Module for Basesystem 15 (src):    ncurses-6.1-5.6.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 28 Swamp Workflow Management 2019-11-23 23:11:11 UTC
openSUSE-SU-2019:2551-1: An update that solves two vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1103320,1154036,1154037
CVE References: CVE-2019-17594,CVE-2019-17595
Sources used:
openSUSE Leap 15.1 (src):    ncurses-6.1-lp151.6.3.1
Comment 29 Swamp Workflow Management 2019-11-23 23:14:33 UTC
openSUSE-SU-2019:2550-1: An update that solves two vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1103320,1154036,1154037
CVE References: CVE-2019-17594,CVE-2019-17595
Sources used:
openSUSE Leap 15.0 (src):    ncurses-6.1-lp150.9.1