Bug#1010806: apt: Avoid color output on monochrome terminals
On Mon, May 16, 2022 at 08:15:16PM +0200, Axel Scheepers wrote:
> On Mon, May 16, 2022 at 6:30 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > 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.
>
> I think you are mistaken here. There's no need to pass environment variables,
> if you run a serial terminal you are supposed to set the proper type, by using
> systemd's Environment setting in serial-getty@service or otherwise
> (i'm more used to gettytab). Not the other way around on the client side.
And how, pray tell, may I know in advance what terminal will be used on the
other end of the serial link? Especially if it's a box people ssh into from
random places, using a plethora of various terminals on their side?
That's the most typical setup these days.
> A common setting, certainly for a rescue terminal, is vt100. When you look at
> terminfo you'll see it defines some common things like how to handle backspace
> (this should sound familiar when you've been running *nix for some
> time as it was
> a big problem in the dialup era).
"vt100" is not a common setting for some decades now, and it differs quite a
bit from what modern terminals offer. Both by lacking capabilities people
take for granted, and by having some no sane terminal bothers to implement
today. Thus it's a pretty bad choice.
> When your function or arrow keys don't work
> properly for instance this is the way to fix that.
Most function keys are not representable via termcap nor terminfo, and TERM
strings are overloaded anyway between diverse terminals (like xterm vs libvt
vs konsole vs ...).
> > 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).
>
> Using curses (and therefor terminfo/termcap) has been the proper way to
> handle different terminals for years.
Until late 80s maybe. By the 90s using curses in a diverse setting meant
lackingdetailslikespaces (this example is IRIX curses vs Linux console), as
vendors stopped maintaining termcap databases.
>A vt100 does *not* support color, a thing which terminfo tells you when you
> run infocmp.
vt100 also stopped being manufactured before the average user has been even
born.
> > Ie, this patch doesn't work, and I see no way to make it work.
>
> The patch was the smallest addition I could think about without including
> a dependency on curses. Please reconsider using color only on terminals
> which 'want' to use them.
The only way I can see your idea to work, would be a list of ancient
terminals that lack color (either handcrafted or queried via termcap), and
relying on the user setting one of those. But that way would be way way too
niche to bother implementing in apt, I'd say.
Thus, as ways to disable color go, I don't see your patch as viable.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural →
⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India.
⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan.
⠈⠳⣄⠀⠀⠀⠀ Germans: IE people who came ~2800BC to Scandinavia; not aryan.
Reply to: