[bug-notifications] [screen 0004133]: Color support impaired, screen windows default to TERM=vt100
Mantis Bug Tracker
noreply at opencsw.org
Thu Apr 15 20:37:11 CEST 2010
A NOTE has been added to this issue.
======================================================================
http://www.opencsw.org/mantis/view.php?id=4133
======================================================================
Reported By: skayser
Assigned To: yann
======================================================================
Project: screen
Issue ID: 4133
Category: packaging
Reproducibility: N/A
Severity: feature
Priority: low
Status: feedback
======================================================================
Date Submitted: 2010-01-09 18:28 CET
Last Modified: 2010-04-15 20:37 CEST
======================================================================
Summary: Color support impaired, screen windows default to
TERM=vt100
Description:
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
workaround though.
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
/usr/lib/share/terminfo database.
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.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0004143 cswmigrateconf should print the warning...
======================================================================
----------------------------------------------------------------------
(0007860) skayser (administrator) - 2010-04-15 20:37
http://www.opencsw.org/mantis/view.php?id=4133#c7860
----------------------------------------------------------------------
After a brief discussion with Phil (who would like to avoid the ncurses
dependency), I revisited this issue and the
setenv TERMINFO /opt/csw/share/terminfo
in the global screenrc file doesn't only make subprocesses happy when it
comes to terminal capabilites, but also screen itself - even when screen is
*not built against our ncurses*. Screen will pick up our terminfo db and
screen windows properly default to "screen".
Currently, this doesn't make the dependency on CSWncurses obsolete though
because our terminfo db is part of CSWncurses. Already a while ago, Maciej
changed the ncurses build recipe to split off a CSWterminfo package, but it
hasn't yet been released as such. Will ping him and/or file a bug against
ncurses.
More information about the bug-notifications
mailing list