Mail Archives: cygwin/2009/09/01/18:58:13
> 'term screen-256color' sets TERM=screen-256color in the
> environment of programs running inside screen, hence any program or
> script that recognises "screen" but not "screen-256color" will no
> longer work as expected.
Btw, a different approach to enabling 256 colour support by default,
which doesn't suffer from the problem above and which wouldn't require
any faffing about with the TERM variable, would be to bump the
'colors' capability in the "xterm", "rxvt" and "screen" terminfo
entries from 8 to 256.
Unfortunately that's not without compatibility issues either though,
which affect remote connections. When connecting from Cygwin to a host
where those terminfo entries still say 8 colours, 256 colour support
would be lost again. Not really a problem though, more just a
limitation.
The other way round is slightly more problematic. When connecting from
another host to Cygwin, the other system's xterm, rxvt or screen might
not actually support 256-colour sequences. Yet the application running
on Cygwin would think that it did based on the local terminfo entry.
This would likely result in no colours at all.
Then again, with the 256 colour codes having been around for quite a
long time, and Cygwin not exactly being a popular server platform,
this scenario seems rather unlikely.
(The underlying issue here is that the whole $TERM/termcap/terminfo
design is fundamentally broken. The sensible thing to do would be for
applications to directly ask the terminal they're actually connected
to about its capabilities, rather than consult a humungous local
database of mostly long-forgotten terminal types that's pretty much
guaranteed to be out-of-date.)
Andy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -