Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
Brian Mays <brian@debian.org> writes:
> 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.
These are all programs that don't use the standard ncurses interface,
I believe. As such, they aren't really good examples.
> 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.
But could be a problem with your below profile example.
> Other than the home key, the end key, and X11 mouse support, there are
X11 mouse support is something that is important to me personally.
Home and end keys aren't that important since most apps don't handle
them correctly anyway.
> 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.
Or we could forget about trying to adapt to a B&W screen until such a
thing happens and just set it to rxvt. After all, the Linux console
doesn't automatically remove colors when not used on a color system.
And how many people are using true monochrome graphics anymore anyway?
AFAIK, the latest PC monitor that did that was the old Hercules (sp?)
card used in XTs. I don't think XFree86 even supports that card
anymore. Most of the non-color monitors I've seen for PCs these days
are simply grayscale VGAs. They look like color monitors to the PC.
I think that if we start worrying terribly about people who have 1-bit
displays, that we are going to be doing a lot of unnecessary hacks to
the system. Remember, we're talking about a display here that cannot
even do bolding correctly.
> 2) Strive for compatibility:
>
> Not all Unices have an rxvt terminfo entry. The RS6000 and SGI
The standard termcap/terminfo out there (distributed by esr I believe)
has those entries. It is not our job to take care of OSs with
obsolete termcap and terminfo stuff. (There is no excuse for no
xterm-color entry -- the color xterm has been in X for years)
> 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.
A simple script in the profile on those machines would fix it. Eg, if
TERM is rxvt or xterm-color, set it to xterm.
> 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.
If this is the default behavior of rxvt, how come the Debian version
doesn't do this? I'm running in 16-bit color mode and it still sets
it to xterm.
> 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}
Which would break if colorterm is set to rxvt-xpm.
> 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.
I think we should make it work as often as possible, thus setting TERM
to rxvt on color and either doing the same thing for monochrome or
setting to xterm for mono.
I strongly disagree with the notion of breaking a program for all
users of displays greater than 1 bit just for the sake of making sure
that it works exactly like it does on 1-bit displays.
> 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.
This could be a good idea, but again, I don't think it justifies
breaking things for people on displays greater than 1 bit. Even
standard VGA has 16 colors and would support color rxvt. I really
have not seen a 386 or better running anything older than VGA, and VGA
(or SVGA) always has at least 16 colors available. In fact, do we
even have any Debian users on 1-bit displays? I suppose it would be
possible to have somebody accessing a Debian machine from some old X
terminal, but still, if the color thing is messing them up, they can
set the TERM variable manually -- better than asking every user of a
non-monochrome display to do so.
--
John Goerzen | Running Debian GNU/Linux (www.debian.org)
Custom Programming |
jgoerzen@complete.org |
--
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: