Description of problem: screen ignores the terminal type setting, either via the command line option -T or via the .screenrc setting "term". It always sets TERM=screen.xterm-256color, but this is incompatible when SSH-ing into older systems that don't have that terminal type defined. I wish to set TERM=screen. Version-Release number of selected component (if applicable): screen-4.4.0-1.fc24.x86_64 How reproducible: always Steps to Reproduce: 1. screen -T screen 2. edit .screenrc, set "term screen" 3. Actual results: >env|grep TERM TERM=screen.xterm-256color Expected results: >env|grep TERM TERM=screen Additional info: I'm using tcsh if that matters.
ssh into e.g. CentOS 5 system: tcsh: No entry for terminal type "screen.xterm-256color" tcsh: using dumb terminal settings.
Issue has been reported to upstream.
Copied from bug #1350549: Charles R. Anderson 2016-09-01 14:02:50 EDT 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. [reply] [−] Comment 7 Charles R. Anderson 2016-09-01 14:10:01 EDT 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 [reply] [−] Comment 8 Charles R. Anderson 2016-09-01 14:36:07 EDT 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
I thought I knew what was cuasing this problem, but I still don't. I moved /etc/profile.d/256term.* out of the way, and the problem still happens. -T should set the terminal type inside screen, but instead it seems to apply some kind of heuristic. For example, if I use -T foo I get TERM=vt100: tcsh>env|grep TERM COLORTERM=truecolor TERM=xterm-256color tcsh>screen -c /dev/null -T foo tsch>env|grep TERM TERM=vt100 TERMCAP=SC|vt100|VT 100/ANSI X3.64 virtual terminal:\ COLORTERM=truecolor If I use -T xterm, I get TERM=xterm. If I use -T xterm-256color, TERM=xterm-256color. If I use -T screen-256color, I get TERM=screen-256color. If I use -T screen, that's when I get the problem this bug is about: tcsh>env|grep TERM COLORTERM=truecolor TERM=xterm-256color tcsh>screen -c /dev/null -T screen tcsh>env|grep TERM TERM=screen.xterm-256color TERMCAP=SC|screen.xterm-256color|VT 100/ANSI X3.64 virtual terminal:\ COLORTERM=truecolor (The problem being that screen.xterm-256color isn't defined on most systems terminfo databases--only Fedora 24 has it, so it fails even when SSH-ing into Fedora 23.) Somehow "screen" is munging TERM. I did more tests not using -T, but just using the parent TERM setting: tcsh>env TERM=xterm screen -c /dev/null tcsh>env | grep TERM TERM=screen tcsh>env TERM=xterm-256color screen -c /dev/null tcsh>env | grep TERM TERM=screen.xterm-256color TERMCAP=SC|screen.xterm-256color|VT 100/ANSI X3.64 virtual terminal:\ COLORTERM=truecolor So it appears that when TERM=screen in the parent shell, or -T screen is passed in, screen always changes it to "screen.xterm-256color". This is surprising undesirable behavior when explicitly setting -T screen or .screenrc "term screen".
Charles, we are currently exploring the wonderful world of terminal definitions in Debian as well, basically see: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color." https://bugs.debian.org/854414 for more than you ever wanted to know about it. I did some testing and research and yes screen mangles TERM, but only under specific conditions, it appears to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854414#86 Additionally it appears that only GNU screen needs any special terminal definitions: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854414#96 tmux, xterm and Konsole *just* don´t care at all. It seems.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.