This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

Andrew Schulman:
>>>> Instead of specifying -T screen-256color every time, one can just put
>>>> 'term screen-256color' into .screenrc. ÂI'll update the docs to show this
>>>> when I make the release current.
>>> Is there any reason that I shouldn't put this command into the default
>>> /etc/screenrc file?
>> 'fraid so. Prompted by this thread I wondered the same thing about
>> mintty: why not set TERM to "xterm-256color" by default?
>> Answer: because /etc/termcap doesn't know about it, and other programs
>> that read the TERM variable might not recognise it either.
>> Furthermore, user startup scripts that compare TERM to "xterm" or
>> "screen" would break.
> You're talking about setting e.g. TERM=xterm-256color in the environment by
> default, but I was asking whether it would cause any harm to put 'term
> screen-256color' into the default /etc/screenrc. ÂKnow any reason that I
> shouldn't?

Well, yes. '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.

Furthermore, 'term screen-256color' (or '-T screen-256color') does not
activate 256-color mode in screen. It it screen querying terminfo and
finding that it is itself running in a 256-color terminal that does

Hence, when screen is started with the usual TERM setting of "xterm"
or "rxvt", you'd end up telling programs running inside screen that
256 colors are available when that isn't actually the case.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]