Bugzilla – Bug 1103320
screen running with TERM=screen.xterm is broken
Last modified: 2019-11-23 23:37:10 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.
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.
So where's the bug I should fix? Anyway, you could try to start screen with the '-a' option.
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?
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.
"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)
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)
bug 1095661 has updates for bash/libreadline to fix ctrl-arrow in screen
Wow, I wonder how that screen.xterm entry got created. It's insane that there are so many differences.
(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
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.)
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.
(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
I do not know anything about terminfos, but I need working cursor keys in my ssh sessions within screen. Fixes are welcome.
(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
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.
(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
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.)
This is an autogenerated message for OBS integration: This bug (1103320) was mentioned in https://build.opensuse.org/request/show/650614 Factory / ncurses
(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!)
This is an autogenerated message for OBS integration: This bug (1103320) was mentioned in https://build.opensuse.org/request/show/651982 Factory / ncurses
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
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
Should be fixed
Thanks Werner!
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.
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
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