Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
>>>>> "Brian" == Brian Mays <brian@debian.org> writes:
Brian> rxvt (and rxvt-xpm) always exports the variable "COLORTERM"
Brian> so that programs can check for color support.
>>>>> "John" == John Goerzen <jgoerzen@complete.org> writes:
John> Unfortunately, I know of no programs that make use of this
John> variable. In fact, I believe that ncurses doesn't even use
John> it.
The rxvt authors claim that programs such as JED, slrn, Midnight
Commander check this variable. I don't know since I don't use any of
these applications.
Brian> As a side note, when XPM support has been compiled into
Brian> rxvt (as with rxvt-xpm supplied in Debian's rxvt package),
Brian> the value of COLORTERM is set to "rxvt-xpm" instead of
Brian> "rxvt".
John> Which could be a bug in itself since Debian has no rxvt-xmp
John> terminfo entry.
This is not a problem since ncurses uses the TERM variable and not the
COLORTERM variable.
John> I would suggest that rxvt set TERM to rxvt when on a color
John> display and to xterm when on a non-color display. The rxvt
John> entry in terminfo already has color support; the xterm entry
John> is monochrome. Since rxvt is backwards-compatible with
John> xterm, this would seem to be the proper method. It would
John> cause the least fuss while ensuring proper behavior in all
John> situations.
John> Even if this isn't done, I suggest that the default be set
John> to rxvt. After all, we have the terminfo entry for it, it
John> doesn't make any sense not to use it.
Observe the difference between the rxvt entry and the xterm-color
entry:
$ infocmp rxvt xterm-color
comparing rxvt to xterm-color.
comparing booleans.
comparing numbers.
comparing strings.
kend: '\EOw', '\EOe'.
khome: '\E[H', '\EO\200'.
kmous: NULL, '\E[M'.
Other than the home key, the end key, and X11 mouse support, there are
no differences between the two entries. Therefore, unless we really
care about these three features, using TERM=xterm-color is good
enough.
I think that we have two choices:
1) Strive to be totally correct:
Convince the ncurses maintainer to provide two rxvt terminfo entries:
one with color capabilities defined and one without color capability.
The rxvt program will set the TERM variable to the appropriate entry
according to the color depth of the X display.
2) Strive for compatibility:
Not all Unices have an rxvt terminfo entry. The RS6000 and SGI
machines on which I have accounts do not have an rxvt entry or an
xterm-color entry. Thus when I rlogin onto these machines from an
rxvt window, the terminal capabilities will default to those of a
"dumb" terminal because TERM=rxvt and TERM=xterm-color are unknown
terminal types to them.
With this mind, rxvt will set the TERM variable to xterm or
xterm-color depending on the color depth of the X display. This is
the default behavior of rxvt provided by the upstream maintainers,
so it should be consistent with rxvt version compiled on non-Debian
Unices.
Users who insist on using the rxvt terminfo entry can monitor the
COLORTERM variable. For example, they can place the following in
their .profile file:
TERM=${COLORTERM:-$TERM}
What I want to avoid is TERM=rxvt on color displays and TERM=xterm on
mono displays. I can see this leading to bug reports when the HOME
and END keys work on color displays but fail to behave the same way on
mono displays. For consistency sake, these keys should either always
work or always not work.
John> I suspect that rxvt would behave properly in this case even
John> if it is on a 1-bit (B&W) display.
The problem is not whether rxvt does the right thing, we need to
ensure that the programs running in an rxvt terminal do the right
thing. This means that when rxvt's window is located on a monochrome
display, the programs running on that window should know that they are
on a terminal that does not have the capability to display colors.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: