On 2017-06-22 16:03 +0200, Axel Beckert wrote:
> Martin Steigerwald wrote:
>> My finding is that current Debian Stretch screen behaviour breaks SSH
>> sessions
>> to many other systems by adding "screen." to the terminal name in $TERM and
>> by
>> not using just "screen" as Debian Jessie´s screen did. See SLES 12 SP2 and
>> CentOS 7 as two examples below.
>
> Thanks for the details. Will check more details later as I haven't
> looked at all of it yet.
>
> But I at least found out what caused it and why I never ran into this
> issue so far myself.
>
> What caused it and how to mitigate it:
>
> 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.
> Because screen only prepends "screen." if it finds the according
> termcap definitions locally. And that definition seems to having been
> added to ncurses-term during the Stretch release cycle. From
> /usr/share/doc/ncurses-term/changelog.gz:
>
> | 20150627
> | [...]
> | + comment-out "screen.xterm" entry, and inherit
> screen.xterm-256color
> | from xterm-new (report by Richard Birkett) -TD
That's correct, systems running older ncurses versions lack that
terminal description.
> 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.
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?
> 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].
> 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… :-/
> The other reason why I never ran into that (e.g. with CentOS 7, RHEL
> 5/6/7, OpenWRT, FreeWRT, etc.) is that I nearly never do SSH inside
> screen but nearly always first use ssh and then start screen on the
> remote machine. (I even have a shell alias for that.)
I agree that starting screen on the remote machine makes more sense -
provided that it is installed there in the first place.
Cheers,
Sven
1.
https://git.gnome.org/browse/vte/commit/?id=82a8b0697dd948fa488b5a51ee7391deb35d49be
2. https://savannah.gnu.org/bugs/?48848
3. https://bugzilla.redhat.com/show_bug.cgi?id=1357981
--
There are a numerous problems with $TERM per se. It's by design a legacy crap.
-- Egmont Koblinger
