> '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
