screen 256 colour TERM setting breaks logging into older hosts

[Paul Gortmaker]

As of 16.04, the screen program started using a 256 colour setting. The problem is that this setting is relatively new and has not had a chance to propagate to older hosts, including something as new as the previous 15.x release. For example:

--------------------------------------
paul@1604-host:~$ echo $TERM
screen.xterm-256color
paul@y1604-host:~$ ssh oldermachine
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-84-generic x86_64)

 * Documentation: https://help.ubuntu.com/

0 packages can be updated.
0 updates are security updates.

Last login: Mon Oct 23 15:52:17 2017 from yow-pgortmak-d1.wrs.com
paul@oldermachine:~$ echo foo > foo
paul@yoldermachine:~$ less foo
WARNING: terminal is not fully functional
foo (press RETURN)
paul@oldermachine:~$ export TERM=screen
paul@yoldermachine:~$ less foo
foo
paul@oldermachine:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.04
DISTRIB_CODENAME=vivid
DISTRIB_DESCRIPTION="Ubuntu 15.04"
paul@oldermachine:~$
------------------------------------------

This makes it extremely annoying to use 16.04 in order to interact with any other linux/unix machines. The 256 color term type needs at least a couple years roll-out time before it becomes the default. Otherwise the older machines won't have it and they will complain and default to ancient crippled defaults and nag you each time they have to do so.

[Egmont Koblinger (egmont-gmail)]

I'm not sure why newer versions of screen (or Ubuntu's configuration) tend to set this weird value of "screen.xterm-256color". The more readable value "screen-256color" is supported at least since Trusty 14.04 (see https://packages.ubuntu.com/trusty/all/ncurses-base/filelist), probably much earlier than that (I'm seeing forum posts about "screen-256color" dated 2011-ish).

I recommend that you configure your local screen to set this value instead.

Indeed screen setting a new value of "screen.xterm-256color" that hasn't had years to get deployed across systems is a bug.

(On a somewhat related note, this whole architecture is plain dead broken. ssh'ing and friends should transfer the entire description of the current terminal's behavior, not just a name. Then we wouldn't have to wait for years, anything new would be usable straight away.)

[Axel Beckert (xtaran)]

Please see this new section in README.Debian, which will be published with the next upload of Debian's screen package to Debian Unstable: https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/README.Debian#n142

I don't see any other feasible solution to this problem from the side of the screen package.

[Egmont Koblinger (egmont-gmail)]

I _guess_ it shouldn't be that hard to patch screen to make an exception to the "prepend 'screen.'" rule, and convert an implicitly created "screen.xterm-256color" into "screen-256color". (I haven't checked screen's source to see how easy it would be.)

This would go against its current documentation, so the documentation should be updated and probably a similar README.Debian entry should also be created. Also, before doing this, it should be examined and understood what's the difference between these two terminal descriptions (at least the file themselves are not exactly byte-by-byte the same).

Alternatively, a similar workaround could go into shell startup files (probably /etc/bash.bashrc and /etc/zsh/zshrc) instead.

If we're saying documenting the issue in screen's README.Debian is enough (as it might easily be, presumably there'll be tons of forums out there pointing to this file), the current addition really nicely summarizes the available workarounds, thanks!

[Axel Beckert (xtaran)]

I do not want to add any further patches to Debian's screen package which makes it differ from upstream behaviour more than it already does. (Of course, it's a different thing if issues are caused by existing patches.)

And IMHO workarounds for issues in other packages do not belong into shell startup files either. (Saying this with my Debian Zsh Team hat on.)

Additionally, after the long and thorough discussion in the Debian bug report (and additional discussions on the ncurses-term topic on IRC), I'm convinced that there is no perfect solution. If you change something to make screen usable in scenario X, it will make people using screen in scenario Y unhappy and vice versa.

Even moving definitions from ncurses-term to ncurses-base doesn't make things better by default: It may help to SSH from older systems with ncurses-term to newer systems with just ncurses-base installed. But it will also cause issues for people SSHing from newer systems with just ncurses-base installed to older systems with an older version of ncurses-base installed. (Not having ncurses-term at all and all definitions in ncurses-base might look like a solution, but then it will which definitions are in that package at which version...)

So yes, IMHO the best thing we can do is document the issue. (And improvements for the documentation are always welcome. :-)

If you really think a behavioural change is needed in screen, then please make according suggestions upstream and submit patches there.

[Paul Gortmaker (paul-gortmaker)]

So, something that used to work and now does not -- the boilerplate definition of a regression, I'd think -- and the "solution" is to update a distro specific README file, that nobody will read? It is your call in the end, but I have to say that doesn't improve the end-user experience any....

[Axel Beckert (xtaran)]

Hi Paul,

Paul Gortmaker wrote:
> So, something that used to work and now does not -- the boilerplate
> definition of a regression,

No, it's no regression in this case:

Screen's behaviour hasn't changed at all. But it's long-standing
behaviour relies a lot on which termcap definitions are available, and
that depends on ncurses-term being installed or not on the remote (and
partially also on the local) side as well as which termcap definitions
are in ncurses-base and which are in ncurses-term. And that changes
over time. See the README "that nobody reads".

IMHO this is neither a regression nor an issue with screen's code nor
can it be fixed without causing _real_ regressions, which I'd like to
avoid.

It might be an issue with the logic implemented in screen since many,
many years if not decades. But I surely won't change such a
long-standing behaviour as a distribution-only patch.

  Regards, Axel
--
 ,''`. | Axel Beckert <email address hidden>, https://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

[Launchpad Janitor (janitor)]

This bug was fixed in the package screen - 4.6.2-1

---------------
screen (4.6.2-1) unstable; urgency=medium

  * Import new upstream release.
    + Refresh patches where necessary.
    + Add fixes for new typos found by Lintian to
      debian/patches/64-fix-manpage-typos-reported-by-lintian.patch.

 -- Axel Beckert <email address hidden> Wed, 25 Oct 2017 19:48:01 +0200