[bug-notifications] [screen 0004133]: Color support impaired, screen windows default to TERM=vt100
Mantis Bug Tracker
noreply at opencsw.org
Mon Jan 11 20:48:43 CET 2010
A NOTE has been added to this issue.
Reported By: skayser
Assigned To: yann
Issue ID: 4133
Date Submitted: 2010-01-09 18:28 CET
Last Modified: 2010-01-11 20:48 CET
Summary: Color support impaired, screen windows default to
Screen is linked to the standard Solaris curses which doesn't know about
"screen" in its terminfo database (/usr/lib/share/terminfo). Thus, screen
windows default to TERM=vt100 and even "screen -T screen" reverts back to
TERM=vt100. The problem with this is that the vt100 terminfo entry doesn't
support colors, so applications like vim running inside screen don't
colorize their output even though screen comes with color support.
To work around it, one can point the system curses libs to the terminfo
database that comes with CSW ncurses (it contains a terminfo description
for screen) and then start screen. "TERMINFO=/opt/csw/share/terminfo
screen". This way screen windows default to TERM=screen and color support
for applications running inside these windows is working. This is a
As a possible fix from the packaging side, screen could be compiled
against CSW ncurses (for comparison: the screen from sunfreeware.com is
also linked against their ncurses). Then the terminfo database defaults to
/opt/csw/share/terminfo and screen windows would have TERM=screen as
described above. The problem with this approach would be that applications
linked against system curses (like /usr/bin/less) running inside our CSW
screen would be presented with TERM=screen which is unknown to their
I don't see this as a major problem though: users are already advised to
put /opt/csw/bin first in their $PATH. If we make sure that our packages
are built against CSWncurses, our stack is fully functional within such a
screen and comes with functional color support out of-the-box. "Legacy"
tools linked against system curses which are running inside such a screen
session would require the TERMINFO workaround from above to understand
TERM=screen or would need to be run with TERM=vt100.
Filing this as a "feature request", which is up for discussion. Right now,
there is no out-of-the-box color support within screen windows.
(0007210) skayser (administrator) - 2010-01-11 20:48
Thanks Yann! Package looks good to me on first sight. Will run it another
two days with my typical usage to see whether anything unexpected pops up.
There is one minor glitch: when someone opens this build of screen and
SSHs to another systems his TERM=screen settings will be carried over
automatically by SSH, but his $TERMINFO won't. So if the target system
happens to be a Solaris system also (or one where some of the applications
don't understand TERM=screen) we will, depending on the application, have
the "unknown term" issue again.
In my opinion this is again a minor problem though. We can't take care of
all systems that a user has access to. And if those target systems don't
understand TERM=screen that's their fault (sounds harsh, but that's the way
I perceive it).
What we can do though, is to offer a documented workaround in README.CSW.
Right now for example, I use the following screen command to open a SSH to
affected systems while still carrying over the TERMINFO variable (no need
to tweak sshd_config and ~/.ssh/environment).
:screen -t build10x ssh -t build10x "TERMINFO=$TERMINFO $SHELL"
Another easy option might be to simply call ssh with an overriden TERM
That defeats color support again, but well ...
More information about the bug-notifications