Sven Joachim - 13.07.17, 10:16: > On 2017-06-22 16:03 +0200, Axel Beckert wrote: […] > > 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.
Ideally I think screen would recognize that the remote machine doesn´t have
the terminal description and try from fallback terminal (i.e.
"screen-256color" which appears to work nice on all Debian 8, CentOS 7, SLES
12). Like:
fallbackterm screen-256color screen
But that would be an upstream feature request and I am not sure whether it is
reasonably possible to implement it. If so, I am willing to create one.
> > 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.
As written Konsole is also affected although on first sight on the dependencies
it doesn´t appear to use libvte (I looked down to libkf5pty and libqt5core).
> 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?
I think that would be nice.
> > 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
It appears that "screen-256color" without "-bce" just works fine on CentOS 7:
[root@centostest ~]# rpm -qa | grep ncurses
ncurses-base-5.9-13.20130511.el7.noarch
ncurses-libs-5.9-13.20130511.el7.x86_64
ncurses-5.9-13.20130511.el7.x86_64
[root@centostest ~]# rpm -ql ncurses-base | grep screen-256
/usr/share/terminfo/s/screen-256color
Thats why I currently have:
root@admin:~# grep "^term " /etc/screenrc
term screen-256color
This really works here,
The initscript mentioned in report¹
[root@centostest ~]# rpm -qf /etc/profile.d/256term.sh
initscripts-9.49.37-1.el7_3.1.x86_64
is clearly opt-in:
# Set this variable in your local shell config (such as ~/.bashrc)
# if you want remote xterms connecting to this system, to be sent 256 colors.
# This must be set before reading global initialization such as /etc/bashrc.
# SEND_256_COLORS_TO_REMOTE=1
And it even appears that it would do the *right* thing:
case "$TERM" in
'xterm') TERM=xterm-256color;;
'screen') TERM=screen-256color;;
'Eterm') TERM=Eterm-256color;;
esac
Its just that screen there mangles both "screen" and "xterm256-color" into
"screen.xterm-256color". Strangely it does for both while in the bug² Charles
mentions that for him its does so only for "screen". On my admin VM this works
cause ncurses-term package is installed.
Thus installing ncurses-term package on CentOS 7 as well, but no luck, it just
doesn´t have "screen.xterm-256color"
[root@centostest ~]# rpm -ql ncurses-term | grep 256color
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/s/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/x/xterm+256color
It does however have "screen256-color":
[root@centostest ~]# rpm -ql ncurses-base | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm-256color
I will comment on their bug report that CentOS 7 could *fix*" the issue by
providing this terminal description.
Debian 9 package ncurses-term which has "screen.xterm-256color":
root@admin:~# dpkg -L ncurses-term | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/r/rxvt-unicode-256color
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/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
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/t/tmux-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm+256color
SLES 12 does not seem to have a ncurses-term package at all, their terminal
definitions seem to be in these two packages:
slestest:~ # rpm -ql terminfo-base | grep 256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/r/rxvt-unicode-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/x/xterm-256color
slestest:~ # rpm -ql terminfo | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/s/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm+256color
So they *all* have "screen-256color" and I actually wonder why this isn´t
used.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1357981
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1357981#c4
> > 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.
While it is more secure to only ever start screens on target machines, using a
central screen on an admin machine makes it possible to have sessions of
several machines in one screen. So globally declarding what makes sense does
not take different scenarious in account and implies that everyone should do
it how – it in the opinion of some – makes the most sense.
Like this:
root@admin:~# cat screenrc-demotuxdc
screen bash
title "A"
screen bash
title "A"
screen ssh root@demotuxdc
title "P"
screen ssh root@ns1
title "NS1"
screen ssh root@ldap1
title "L1"
screen ssh root@ldap2
[…]
Thanks,
signature.asc
Description: This is a digitally signed message part.
