[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <449db665-0285-4283-972f-1b6d5e6e71a1@gedalya.net>
Date: Thu, 23 May 2024 21:04:54 +0800
From: Gedalya <gedalya@...alya.net>
To: Dragan Simic <dsimic@...jaro.org>, Sirius <sirius@...dheim.com>
Cc: netdev@...r.kernel.org
Subject: Re: iproute2: color output should assume dark background
On 5/23/24 8:36 PM, Dragan Simic wrote:
> On 2024-05-23 09:57, Sirius wrote:
>> Maybe colouring the output by default isn't such a wise idea as
>> utilities
>> reading the output now must strip control-codes before the output can be
>> parsed.
No. Debian is building with --color=auto, with which colors are added
only when stdout is a terminal.
Just do `ip a | cat` to test.
>
> How about this as a possible solution...
For what problem?
Yes I asked Debian in the first place to leave colors disabled by
default, but nevertheless `ip` is still broken for most users if and
when colors are enabled, whether at runtime or build time.
> If Debian configures the terminal emulators it ships to use dark
> background,
Do they? Or is that the nearly universal default?
> why not configure the ip(8) utility the same way, i.e. by setting
> COLORFGBG in files placed in the /etc/profile.d directory,
COLORFGBG where set is automatically set by the terminal emulator. It
would be more sensible to add this feature to more terminal emulators,
upstream.
Should Debian come up with a patch that magically adjusts this variable
every time the user changes their background color (in one terminal
emulator... and another color in another terminal emulator...?)
And what about linux virtual terminals (a.k.a non-graphical consoles)?
In summary, if the best we can do is manually set COLORFGBG when using a
light background then that's the best we can do. I don't see how Debian
can possibly help with that.
On the iproute2 side, a rock-bottom ultimate default background color
assumption will always be needed and that should be dark.
Yes, echo -ne '\e]11;?\a' works on _some_ (libvte-based) terminals but
not all. And a core networking utility should be allowed to focus on,
ehhm, networking rather than oddities of a myriad terminals.
Powered by blists - more mailing lists