Bug 1350549

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Described reproducer works for me. (Tested on several Fedora 24 installations).

Issue with limited terminal name length has been fixed in screen-4.4.0-1 (in this version is supported terminal name up to 32 characters, but still is there presented typo issue in error message).

There is another known issue with -T parameter (for more information see https://bugzilla.redhat.com/show_bug.cgi?id=1357981)

Try to reinstall this package and check your ~/.screenrc file for correct package setup.

Created attachment 1196056 [details]
Crash log with screen-4.4.0-1.fc24.x86_64

screen 4.4.0-1 still crashes for me with the attached trace when running:

$ screen -T screen.xterm-256color bash

I've tried reinstalling the package but it doesn't fix the problem. My ~/.screenrc is very short, so I'll paste it here.

defutf8 on
vbell_msg ""
startup_message off
shell -$SHELL
defscrollback 20000
caption always "%{.bw} %-w%{.wk}%n %t%{-}%+w"
msgwait 0

This issue has been reported to upstream.

Unfortunately even they are not able to reproduce described problem.

From the conversation with upstream:

-------- UPSTREAM --------
I'm also not sure what may cause this problem, code seems
fairly simple and I can't reproduce it here.

Some ideas to try are to make sure he has right screen (md5sum it and
check 'screen --version'). Also same can be done with libraries screen
is linked with.
Another thing I would check is screen.xterm-256color file itself

Also does it work with other terminfo entries?
Does "screen -c /dev/null" work fine?
--------    END   --------

I will attach screen.xterm-256color to this bugzilla.

Created attachment 1196607 [details]
screen.xterm-256color

path to the file /usr/share/terminfo/s/

I believe the problem is in /etc/profile.d/256term.sh and /etc/profile.d/256term.csh.  The logic seems wrong--they will unconditionally set TERM to the 256color version if local256 is set OR SEND_256_COLORS_TO_REMOTE is set.  local256 is set if any of COLORTERM, XTERM_VERSION, ROXTERM_ID, or KONSOLE_DBUS_SESSION are set.  I do have COLORTERM set inside screen:

>env | grep -E 'COLORTERM|XTERM_VERSION|ROXTERM_ID|KONSOLE_DBUS_SESSION|SCREEN|TERM'
TERM=screen.xterm-256color
TERMCAP=SC|screen.xterm-256color|VT 100/ANSI X3.64 virtual terminal:\
COLORTERM=truecolor

I'm going to reassign this bug to initscripts.

256term.{sh,csh} should not be forcing 256color TERM if the TERM starts with "screen" because this breaks SSH-ing into older systems that don't have terminal types "screen.xterm-256color" and variants defined.  E.g. RHEL 5 has these terminfo entries available:

screen
screen2
screen3
screen-bce
screen.linux
screen-s
screen.teraterm
screen-w
screen.xterm-new
screen.xterm-r6
screen.xterm-xfree86

but it has many more xterm ones available:

xterm
xterm1
xterm-1002
xterm-1003
xterm-16color
xterm-24
xterm-256color
xterm+256color
xterm-88color
xterm+88color
xterm-8bit
xterm-basic
xterm-bold
xtermc
xterm-color
xterm-hp
xtermm
xterm-new
xterm-nic
xterm-noapp
xterm-old
xterm+pcc0
xterm+pcc1
xterm+pcc2
xterm+pcc3
xterm+pcfkeys
xterm-pcolor
xterm-r5
xterm-r6
xterms
xterm-sco
xterm+sl
xterm+sl-twm
xterms-sun
xterm-sun
xterm-vt220
xterm-vt52
xterm-xf86-v32
xterm-xf86-v33
xterm-xf86-v333
xterm-xf86-v40
xterm-xf86-v43
xterm-xf86-v44
xterm-xfree86
xterm-xi

These are the available 256color terminal types on different OSes:

CentOS release 5.11 (Final):

>find /usr/share/terminfo -name '*256*' | sort
/usr/share/terminfo/d/darwin-256x96
/usr/share/terminfo/d/darwin-256x96-m
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/x/xnuppc-256x96
/usr/share/terminfo/x/xnuppc+256x96
/usr/share/terminfo/x/xnuppc-256x96-m
/usr/share/terminfo/x/xterm-256color
/usr/share/terminfo/x/xterm+256color

Scientific Linux release 6.7 (Carbon):

/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/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/x/xterm-256color

CentOS Linux release 7.2.1511 (Core):

>find /usr/share/terminfo -name '*256*'|sort
/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

Fedora release 24 (Twenty Four):

>find /usr/share/terminfo -name '*256*'|sort
/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/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/s/stterm-256color
/usr/share/terminfo/t/tmux-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm-256color

Given that you're unable to reproduce my crash, I'll try to debug it myself this weekend and try to pinpoint the exact cause in the source code, and whether it's a problem with upstream or with Fedora explicitly.

That said, let me add my two cents to other recent comments as a mostly clueless Fedora user. :-)

About the profile.d scripts, I don't know what they have to do with the crash I reported, which happens if you set TERM to a long value and even if you launch a command that's not a shell, like:

$ screen -T test01234567890123456789 sleep 5

The profile.d scripts do not kick in currently in Fedora 24 to set TERM to screen.xterm-256color as long as you launch xterm like this:

$ xterm -tn xterm-256color

Which is useful to tell any app running inside the xterm that your xterm has 256-color support. That app may not be a shell that ends up using /etc/profile. It may be screen, or maybe vim or whatever and may benefit from knowing your xterm has 256-colors support.

To test that, I disabled the scripts by appending the .disabled suffix to the file names (so they don't match *.sh as used by /etc/profile) and ran screen inside an xterm again. screen still sets TERM to screen.xterm-256color when xterm is launched with -tn xterm-256color, so the scripts are not directly reponsible for the TERM value that ends up being used by ssh. screen itself is choosing that value.

Now, I'm far from an expert in terminals, but I understand the terminal type is appropriate because screen with 256-colors support inside an xterm with 256-colors support is a specific terminal type with a given set of features and that grants it having its own terminfo type.

I _do_ like screen choosing that value by itself because I can run "screen vim" and screen will pass the appropriate TERM value to vim so the latter enables 256-colors support without needing anything special in ~/.vimrc, as it should be.

The unfortunate drawback is having ssh pass the TERM value to remote shells, which may be confused as that recently added type may be unknown to them. But I run into problems like those with simple TERM values like "screen" when I connect to old Solaris boxes in my everyday job. It's a problem I believe time will solve and in the mean time I only have to launch ssh with the following script:

#!/bin/sh
case "$TERM" in
   *screen*) export TERM=screen ;;
   *xterm*)  export TERM=xterm  ;;
   *) ;;
esac
exec /usr/bin/ssh "$@"

Sorry for the long text.

I found the problem causing the crash and it's present upstream. I created a patch and filed a bug report in the GNU Screen bug tracker. You can find it here:

https://savannah.gnu.org/bugs/index.php?48983

Sorry for confusing this bug with #1357981.  I've set this one back to the "screen" component, and will change the other one.

Fixed upstream in both the "master" and "screen-v4" branches.

http://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=f3a12f015766becab73d88c5d5c4720c86e14987
http://git.savannah.gnu.org/cgit/screen.git/commit/?id=becc1dfda9068754de72c0bc40df59e46fe5ccd5

Thank you Ricardo. This change will be applied in next release of screen.

screen-4.4.0-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-22dd6fd0bf

screen-4.4.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8b1e2b227

screen-4.4.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-dae4c0bf61

Thanks for the fixed package. Works for me under Fedora 24. Giving karma in bodhi.

screen-4.4.0-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-dae4c0bf61

screen-4.4.0-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8b1e2b227

screen-4.4.0-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-22dd6fd0bf

screen-4.4.0-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a8463729e

screen-4.4.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-29a94027ca

screen-4.4.0-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d7959377c1

screen-4.4.0-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a8463729e

screen-4.4.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-29a94027ca

screen-4.4.0-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d7959377c1

screen-4.4.0-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

screen-4.4.0-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

screen-4.4.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.