Control: tag -1 - moreinfo thanks Dear maintainer(s), dear Axel.
Removing moreinfo tag as I now provide more info than you ever wanted to know and as "moreinfo" tag still being set may have led to lack of maintainer feedback I digged quite a bit deeper into the issue. 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. Since this bug report is still quite sparse on maintainer feedback and adding "export TERM=xterm" or something like that to any affected system is quite tedious. I investigated adding term xterm-256color and later term xterm to "/etc/screenrc", but while this leads to given terminal being set in the screen session, this won´t work nicely either. It will lead to background color in YaST not being painted everywhere. See attached screenshot "screen-term-xterm-256color.png". "no-screen-term- xterm-256color.png" shows how YaST should look like instead. So it appears to me that screen indeed needs some special handling for colors, which seems to be activated by prepending using "screen.xterm-256color" instead of just "xterm-256color" in the current screen package in Stretch. So I finally checked what terminal screen of Debian Jessie sets. And it is just "screen". So I tried: term screen in "/etc/screenrc", but this leads to "screen.xterm-256color". So there seems to be some automagic stuff in screen that adds the original terminal name if the terminal is set to "screen" and I am finally in the mode to just ditch "screen" and try with "tmux" and I am absolutely not in favor of software breaking perfectly fine working things by some automagic that I do not know how to disable. But after trying my way through terminals "vt100" and "ansi" I finally found a work-around to this issue that appears to work: term screen-256color in "/etc/screenrc" appears to work nicely with both SLES 12 and CentOS 7. I really suggest logging into this as this will likely break shell sessions in non-obvious ways for quite some users as they upgrade to Debian Stretch. Even if they just use Debian, cause Debian Jessie also doesn´t know "screen.xterm-256color". So I really ask for the maintainers to step up and think about a solution to this issue and finally fix it. demotuxdcproxy is Debian Stretch. # With SLES12 SP 2, without screen root@demotuxdcproxy:~# ssh root@ldap3 ldap3:~ # echo $TERM xterm-256color => works perfectly # With SLES12 SP 2, with screen root@demotuxdcproxy:~# ssh root@ldap3 ldap3:~ # echo $TERM screen.xterm-256color ldap3:~ # LANG=C vim E437: terminal capability "cm" required Press ENTER or type command to continue => Completely broken, even backspace does not work, however it does not appear to be recognized as an unknown terminal, in "vim" even linefeeds are not displayed # With CentOS 7.3.1611, without screen root@demotuxdcproxy:~# ssh root@ldap2 [root@ldap2 ~]# echo $TERM screen.xterm-256color => Works perfectly # With CentOS 7.3.1611, with screen [root@ldap2 ~]# echo $TERM screen.xterm-256color [root@ldap2 ~]# nmtui-edit Unknown terminal: screen.xterm-256color Check the TERM environment variable. Also make sure that the terminal is defined in the terminfo database. Alternatively, set the TERMCAP environment variable to the desired termcap entry. => Unknown terminal definition. Thanks, -- Martin Steigerwald | Trainer teamix GmbH Südwestpark 43 90449 Nürnberg Tel.: +49 911 30999 55 | Fax: +49 911 30999 99 mail: martin.steigerw...@teamix.de | web: http://www.teamix.de | blog: http://blog.teamix.de Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt teamix Support Hotline: +49 911 30999-112 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***
