Control: tag -1 + confirmed Hi Sven,
thanks again for taking the time to dig into this and providing even more useful information! 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. 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. > > What changed between Jessie and Stretch is that ncurses-term now also > > includes termcap definitions for "screen.xterm-256color" (as shown > > above) > > The other thing that changed is that libvte-2.91-0 now sets > TERM=xterm-256color[1], which means that many people will be affected > since {gnome,mate,xfce4}-terminal and a few other terminal emulators use > libvte-2.91-0. I see. > 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. > > The only programmatic fix I can imagine is to ask upstream to add a > > switch to disable this ancient feature. Which feels kinda wrong, also > > because there seems no related upstream bug report yet. > > There are, however, requests to make the -T switch and "term=screen" > in .screenrc work like that[2,3]. […] > 2. https://savannah.gnu.org/bugs/?48848 > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1357981 Oh, [2] is nice find! Thanks! > > Ah, and FTR: Why I never ran into this myself: > > > > I've added "term screen-256color-bce" to my .screenrc IIRC when xterm > > got 256 colors support, but screen didn't detect it properly. And > > never having removed that again (my fault, yes) hid the issue for me, > > i.e. connecting to Jessie or Wheezy works fine that way. Not with > > CentOS 7 though. > > That's because CentOS 7 puts screen-256color-bce into the ncurses-term > package and the remote system did not have that package installed. On > Debian, screen-256color-bce is in ncurses-base. I suppose we could add > screen.xterm-256color there too, but that's only going to help in four > years or so when buster becomes oldstable and people start to migrate to > it from stretch-LTS, and in the meantime it breaks your workaround to > uninstall ncurses-term… :-/ 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. 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. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
