I just upgraded to Fedora 24 and screen now chooses a TERM value of "screen.xterm-256color" when running under xterm, which is great because 256-colors support is enabled without /etc/profile.d/256term.sh, working on any interactive shell. However, if you choose that same value and pass it as the -T option when creating a new window, screen complains. Tested under screen-4.3.1-4.fc24.x86_64. $ echo $TERM screen.xterm-256color $ screen -T "$TERM" -T: terminal name too long. (max. 20 char) This is a bit contradictory, right? Under screen-4.4.0-1.fc24.x86_64, as of the time I'm writing this a pending update, it's even more confusing. Screen crashes with SIGABRT and the window is closed immediately to much user confusion unless the zombie option is used.
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.