Axel Beckert - 13.07.17, 10:44: > Sven Joachim wrote: > > > Not yet tested, but suspected to mitigate this is to uninstall > > > ncurses-term from the Stretch machine on which screen is running and > > > then exiting and starting the screen session again. > > > > A less drastic measure is to change the TERM variable before running > > screen, e.g. to xterm. > > Good point. But that recommendation seems to depend a lot on what > "screen.something" is provided by ncurses-term.
As written in my reply to Sven: - CentOS 7, ncurses-base - SLES 12, terminfo-base both have "screen-256color". And Debian 8 has too: mondschein:~> dpkg -L ncurses-base | grep 256color /lib/terminfo/x/xterm-256color /lib/terminfo/s/screen-256color-bce /lib/terminfo/s/screen-256color So "screen-256color" seems to be a sweet spot for me. > Another suggestion which is probably worth documenting comes from > https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled > as non-working there: Using "term screen" inside .screenrc. At least > "term screen-256color-bce" worked for me so well that I never noticed > this issue. Ok, I summarize what I see on Debian 9 screen - TERM=xterm-256color screen -T screen => screen.xterm-256color - TERM=xterm screen -T screen => screen - TERM=screen screen -T screen => screen (funny colors in screen status bar, due to due to how Konsole handles TERM="screen", can reproduce this locally, leaving this one out then) And now take this: - TERM=xterm-256color screen -T xterm => xterm (!!?!?!?!) - ERM=xterm screen -T xterm => xterm But then take this: - TERM=xterm-256color screen -T screen-256color => screen-256color - TERM=xterm screen -T screen-256color => screen-256color And this: - TERM=xterm-256color screen -T xterm-256color => xterm-256color - TERM=xterm screen -T xterm-256color => xterm-256color This is no joke: Now if you don´t call this crazy, I will. So whether screen does something with TERM depends on *both* what TERM is set to *and* what "-T" or "term" in /etc/screenrc is set to. A pattern I gazered so far: screen just seems to modify "-T screen", but only if it detects a 256 color mode. Lets try this assumption: - TERM=screen-256color screen -T screen => screen Let me add: But only if its not a "screen-256color" 256 color mode :) But if you thought we would be finished here, take this: - TERM=vte-256color screen -T screen => screen.vte-256color Yet: - TERM=tmux-256color screen -T screen => screen But: - TERM=putty-256color screen -T screen => screen.putty-256color Still as I thought I found a pattern, take this: - TERM=rxvt-256color screen -T screen => screen - TERM=konsole-256color screen -T screen => screen.konsole-256color (Konsole there doesn´t even appear to use this terminal definition!) I think I still found a pattern: root@admin:~# dpkg -L ncurses-term | grep "screen\..*-256color" /usr/share/terminfo/s/screen.konsole-256color /usr/share/terminfo/s/screen.mlterm-256color /usr/share/terminfo/s/screen.putty-256color /usr/share/terminfo/s/screen.vte-256color /usr/share/terminfo/s/screen.xterm-256color Screen will change "-T screen" / "term screen" to "screen.something-256color"… if, and *only* if on the *local* system a corresponding terminal definition does exist. Two ideas: 1. Drop this behavior. 2. *Make this behavior work*. That is, again, reconsider that decision when logging in to remote system. If remote system doesn´t have "screen.something256-color" then use "screen-256color". But even in second case, I´d at least allow to optionally disable that automagic "I surprise you funnily with mangling TERM" behavior. > > If nothing else can be done about it, could the problem and a mitigation > > (e.g. "run TERM=xterm screen if you run into it") at least be mentioned > > in README.Debian? > > Yep, documenting it as a first step is also something which came to my > mind — now that we understand the issue much better. From my experiments above, I´d say: screen-256color appears to be the best "term" option for screen at the moment. […] > Yeah, most recommendations depend a lot on the version respectively on > the exact term definitions included in ncurses-term. *sigh* > > So my current plan is to document the issue in README.Debian with the > following suggestions as workaround, depending on the ncurses-term > versions installed locally and remote: > > * Use "env TERM=xterm screen" (or similar). > * Use "term screen" inside .screenrc > * Uninstall ncurses-term locally or install ncurses-term on the remote > machine. The third option won´t work. See my response to Sven where I listed the exact terminal definitions. ncurses-term on CentOS 7.3.1611 doesn´t contain "screen.xterm-256color" and SLES 12 doesn´t even have a ncurses-term package but also does not seem to have this term def in any of their terminfo packages. > Exact wording still needs to be determined. Suggestions welcome, > especially from users which ran into that issue and hence have a > better feeling what works in which case and what doesn't. I´d say: 1. Permanent work-around: "term screen-256color" in /etc/screenrc of the screen which accesses remote machines. 2. Temporary work-around: "screen -T screen-256color" 3. If "screen-256color" doesn´t work (unlikely with recent distributions) use "screen" I end with a plea to terminal emulator and terminal definition developers: *STOP* inventing new terminal definitions. *Now*. (Inspired by Jordan Sissel´s, Logstash developer, "Don´t invent new time formats") *Pretty please*. Create one standard and ask all terminal developers to adopt it. Of course this will only help within about 10 years, but still. Konsole, Putty, GNOME Terminal, XFCE / MATE / LXDE (Qt), xterm terminals basically all displays chars on the screen… have one terminal definition for 256 colors for all of them :) Thanks,
signature.asc
Description: This is a digitally signed message part.
