Bug#1010806: apt: Avoid color output on monochrome terminals
On Tue, May 10, 2022 at 07:34:25PM +0200, Axel Scheepers wrote:
> Regarding terminal capabilities,
>
> On Tue, May 10, 2022 at 6:04 PM Julian Andres Klode <jak@debian.org> wrote:
> > > in programs. But there's no common characteristic of a terminal that'd
> > > allow autodetecting your wishes.
>
> The 'proper' way would be to query the terminfo entry Co I think. The best way
> to make a terminal program color capable would be to use a terminal library
> like ncurses which handles this for you and has a function `has_colors(void);`
> which does the right thing(tm) :)
The terminfo entries stopped being maintained by late 80's. And even if
they were, every new terminal would need to wait several years before it can
have its definition known by operating systems (today, distributions).
The effect? Most terminals identify as "xterm", "xterm-256color", or
"rxvt". For example both libvt (Gnome-Terminal, etc) and Konsole claim to
be an xterm...
And even if $TERM->terminfo were usable, a serial console has no way to pass
env vars. As an install/rescue tool, apt gets run over a serial console
pretty often.
Thus, using terminfo is definitely not a "Right Thing" this millenium.
Most new programs just hardcode the codes, assuming a vt100-like terminal
with a common set of capabilities. This includes color, as the last
terminal without color that I remember was Windows 3.X/95's telnet.exe
(which, per the vt100 language, ignored unknown SGR codes gracefully).
Ie, this patch doesn't work, and I see no way to make it work.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄⠀⠀⠀⠀ sky. Your cat demands food. The priority should be obvious...
Reply to: