Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357981 - screen ignores -T and .screenrc term setting
Summary: screen ignores -T and .screenrc term setting
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: screen
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Josef Ridky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-19 17:53 UTC by Charles R. Anderson
Modified: 2018-05-29 11:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 11:48:25 UTC


Attachments (Terms of Use)

Description Charles R. Anderson 2016-07-19 17:53:26 UTC
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.

Comment 1 Charles R. Anderson 2016-07-19 17:57:09 UTC
ssh into e.g. CentOS 5 system:

tcsh: No entry for terminal type "screen.xterm-256color"
tcsh: using dumb terminal settings.

Comment 2 Josef Ridky 2016-08-22 07:18:35 UTC
Issue has been reported to upstream.

Comment 3 Charles R. Anderson 2016-09-02 22:08:23 UTC
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

Comment 4 Charles R. Anderson 2016-09-02 22:52:24 UTC
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".

Comment 5 Martin Steigerwald 2017-07-13 10:38:25 UTC
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.

Comment 6 Fedora End Of Life 2017-07-25 21:53:53 UTC
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.

Comment 7 Fedora End Of Life 2018-05-03 08:03:36 UTC
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.

Comment 8 Fedora End Of Life 2018-05-29 11:48:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.