iproute2: color output should assume dark background

iproute2: color output should assume dark background

[Gedalya]

Hello,

Debian is now building iproute2 with color output on by default. This brings attention to the fact that iproute2 defaults to a color palette suitable for light backgrounds.

The COLORFGBG environment variable, if present and correctly set would select a dark background. However COLORFGBG is neither ubiquitous nor standard. It wouldn't typically be present in a non-graphical vt, nor is it presnet in XFCE and many other desktop environments.

Dark backgrounds seem to be the more common default, and it seems many people stick to that in actual use.

The dark blue used by the ip command for IPv6 addresses is particularly hard to read on a dark background. It's really important for the ip command to provide basic usability e.g. when manually bringing up networking at the console in an emergency. I find that fiddling with extra details just to disable or improve the colors would be an unwelcome nuisance in such situations, but the Debian maintainer outright refuses to revert this change, without explanation or discussion.

Instead the maintainer suggested I submit a patch upstream, which I will do. I've never contributed here before, so your patience and guidance would be very highly appreciated.

Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071582

Thanks,

Gedalya

Re: iproute2: color output should assume dark background

[Dragan Simic]

Hello,

On 2024-05-22 21:21, Gedalya wrote:
> Debian is now building iproute2 with color output on by default. This
> brings attention to the fact that iproute2 defaults to a color palette
> suitable for light backgrounds.
> 
> The COLORFGBG environment variable, if present and correctly set would
> select a dark background. However COLORFGBG is neither ubiquitous nor
> standard. It wouldn't typically be present in a non-graphical vt, nor
> is it presnet in XFCE and many other desktop environments.
> 
> Dark backgrounds seem to be the more common default, and it seems many
> people stick to that in actual use.
> 
> The dark blue used by the ip command for IPv6 addresses is
> particularly hard to read on a dark background. It's really important
> for the ip command to provide basic usability e.g. when manually
> bringing up networking at the console in an emergency. I find that
> fiddling with extra details just to disable or improve the colors
> would be an unwelcome nuisance in such situations, but the Debian
> maintainer outright refuses to revert this change, without explanation
> or discussion.
> 
> Instead the maintainer suggested I submit a patch upstream, which I
> will do. I've never contributed here before, so your patience and
> guidance would be very highly appreciated.
> 
> Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071582

FWIW, I'd support the change to dark background as the defult.

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> Hello,

Good morning,

> Debian is now building iproute2 with color output on by default. This
> brings attention to the fact that iproute2 defaults to a color palette
> suitable for light backgrounds.
> 
> The COLORFGBG environment variable, if present and correctly set would
> select a dark background. However COLORFGBG is neither ubiquitous nor
> standard. It wouldn't typically be present in a non-graphical vt, nor is
> it presnet in XFCE and many other desktop environments.
> 
> Dark backgrounds seem to be the more common default, and it seems many
> people stick to that in actual use.

FWIW, I use a light background as that is easier for me to read.

Might I suggest that instead of fueling a bikeshed war about what terminal
background should be used, read what the background is of the console and
adapt the foreground colours to that. I would guess that means holding two
sets of the eight colours and if the background is "dark", use the lighter
set and if the background is "light", use the darker set. Then the
variable is superfluous.

Make it usable for everyone rather than just a subset of users based on
personal preference.

> The dark blue used by the ip command for IPv6 addresses is particularly
> hard to read on a dark background. It's really important for the ip
> command to provide basic usability e.g. when manually bringing up
> networking at the console in an emergency. I find that fiddling with
> extra details just to disable or improve the colors would be an
> unwelcome nuisance in such situations, but the Debian maintainer
> outright refuses to revert this change, without explanation or
> discussion.
> 
> Instead the maintainer suggested I submit a patch upstream, which I will
> do. I've never contributed here before, so your patience and guidance
> would be very highly appreciated.
> 
> Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071582

Kudos for that.

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 2:39 PM, Sirius wrote:
> what terminal background should be used,
It's not about prescribing what should, but about guessing what is, when that is not explicitly stated. The only "right" way to guess is to always choose what is more probable (common, in this case).
> read what the background is of the console
That's COLORFGBG. It is set by some terminal emulators as a way to advertise the colors being used.

I'm no expert but AFAIK there is no uniform way to do this that is supported by all major terminal emulators.

> adapt the foreground colours to that. I would guess that means holding two
> sets of the eight colours and if the background is "dark", use the lighter
> set and if the background is "light", use the darker set.

That's what iproute2 currently does.

In fact this can't be adequate. You can't turn the question of best contrast against 16(million?) different colors into a binary. But this is a simple CLI command, not a full-screen productivity app.

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> On 5/23/24 2:39 PM, Sirius wrote:
> > what terminal background should be used,
> It's not about prescribing what should, but about guessing what is, when that is not explicitly stated. The only "right" way to guess is to always choose what is more probable (common, in this case).

Appeal to authority.

> > read what the background is of the console
> That's COLORFGBG. It is set by some terminal emulators as a way to
> advertise the colors being used.
> 
> I'm no expert but AFAIK there is no uniform way to do this that is
> supported by all major terminal emulators.

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Control-Bytes_-Characters_-and-Sequences
https://stackoverflow.com/questions/2507337/how-to-determine-a-terminals-background-color

If you colour the output, then handling the prospect that the background
might not be the assumed colour kind of comes with the territory.
Or you deliberately set the background colour to something so that it is
not undefined. That is what the ANSI colour sequences can do when you use
strings like \e[32;47m where you deliberately set the background.

> > adapt the foreground colours to that. I would guess that means holding
> > two sets of the eight colours and if the background is "dark", use the
> > lighter set and if the background is "light", use the darker set.
> 
> That's what iproute2 currently does.
> 
> In fact this can't be adequate. You can't turn the question of best
> contrast against 16(million?) different colors into a binary. But this
> is a simple CLI command, not a full-screen productivity app.

If the background as read from terminal is > 127 it is "light", if it is <
127, it is "dark".

Xterm, the sequence \e]11;?\a will give you the background colour, zutty
does too, urxvt does not.

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. Why not leave it as an option via the -c[olor] switch like before?

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Sirius thus quoth: 
> In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> > On 5/23/24 2:39 PM, Sirius wrote:
> > > read what the background is of the console
> > That's COLORFGBG. It is set by some terminal emulators as a way to
> > advertise the colors being used.
> > 
> > I'm no expert but AFAIK there is no uniform way to do this that is
> > supported by all major terminal emulators.
> 
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Control-Bytes_-Characters_-and-Sequences
> https://stackoverflow.com/questions/2507337/how-to-determine-a-terminals-background-color
> 
> If you colour the output, then handling the prospect that the background
> might not be the assumed colour kind of comes with the territory.
> Or you deliberately set the background colour to something so that it is
> not undefined. That is what the ANSI colour sequences can do when you use
> strings like \e[32;47m where you deliberately set the background.

https://github.com/dalance/termbg

Someone already did the hard work. Just use that library and you can
detect the background colour or whether a theme is light or dark.

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Dragan Simic]

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. Why not leave it as an option via the -c[olor] switch like 
> before?

How about this as a possible solution...  If Debian configures the 
terminal
emulators it ships to use dark background, why not configure the ip(8) 
utility
the same way, i.e. by setting COLORFGBG in files placed in the 
/etc/profile.d
directory, which would also be shipped by Debian?

That wouldn't be a perfect solution, of course, but would be more 
consistent.
Debian ships terminal emulators configured one way, so the ip(8) should 
also
be shipped configured (mind you, not patched) the same way.

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Dragan Simic thus quoth: 
> 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. Why not leave it as an option via the -c[olor]
> > switch like before?
> 
> How about this as a possible solution...  If Debian configures the
> terminal emulators it ships to use dark background, why not configure
> the ip(8) utility the same way, i.e. by setting COLORFGBG in files
> placed in the /etc/profile.d directory, which would also be shipped by
> Debian?

That makes more sense.

> That wouldn't be a perfect solution, of course, but would be more
> consistent.  Debian ships terminal emulators configured one way, so the
> ip(8) should also be shipped configured (mind you, not patched) the same
> way.

This is a much better argument - Thank you. Something for the
distributions to consider should they turn on the colour by default.

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Gedalya]

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.

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> 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.

Then it perhaps should not add colour to the output in the first place and
focus solely on the networking.

A suggestion would be the iproute2 package revert the option to compile
colourised output as default, sticking to plain text output as that
require zero assumptions about the user terminal. Carry on offering the
'-c' switch to enable it at runtime.

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 15:04, Gedalya wrote:
> On 5/23/24 8:36 PM, Dragan Simic wrote:
>> On 2024-05-23 09:57, Sirius wrote:
>> How about this as a possible solution...
> 
> For what problem?

Obviously, for the problem your patch attempts to solve.

> 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.

Well, the coloring support in ip(8) can't be broken if the users
configure it at runtime accordingly, i.e. following the background
color configured in their terminal emulator(s), right?  Or am I
misunderstanding something?

>> If Debian configures the terminal emulators it ships to use dark
>> background,
> 
> Do they? Or is that the nearly universal default?

Frankly, I don't know for sure because I don't use many different
terminal emulators, but you as the submitter of this patch perhaps
should know that better.  However, terminal emulators must be
configured somehow, because it makes no sense whatsoever that they're
having their background colors hardcoded.

>> 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.

Of course, but that would take a lot of time, both to implement it
everywhere and for the new feature to reach the users.  Shipping
a few additional files in the /etc/profile.d directory would be a
reasonable stopgap measure.

> 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...?)

That's a valid concern.  Perhaps some documentation could be provided,
to help the users who alter their background colors.

> And what about linux virtual terminals (a.k.a non-graphical consoles)?

In my 25+ years of Linux experience, I've never seen one with a 
background
color other than black.

> 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.

As others already pointed out, "should be light" or "should be dark"
can be seen as personal preference.

> 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.

In an ideal world, yes.

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 9:23 PM, Dragan Simic wrote:

>> For what problem?
>> Obviously, for the problem your patch attempts to solve.

When nothing is indicated and a genuine _guess_ must be made, or a _default_ should be set, should that be dark or light?
This is not a coding question.
All defaults should be good in some situations and bad in fewer situations.
Having a default does not preclude reducing the number of cases it is relied upon. Those are different matters.

>> 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.
> Well, the coloring support in ip(8) can't be broken if the users
> configure it at runtime accordingly, i.e. following the background
> color configured in their terminal emulator(s), right?

Absolutely right. The manpage says so and it is tested, working.

>>> If Debian configures the terminal emulators it ships to use dark
>>> background,
>> Do they? Or is that the nearly universal default?
> Frankly, I don't know for sure because I don't use many different
> terminal emulators, but you as the submitter of this patch perhaps
> should know that better.  However, terminal emulators must be
> configured somehow, because it makes no sense whatsoever that they're
> having their background colors hardcoded.

If you use the word "configure" to refer to the default behavior, set by 
upstream and not modified by the distribution, then fine, yes.

It's just a way of saying "terminals tend to be dark".

>>> 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.
> Of course, but that would take a lot of time, both to implement it
> everywhere and for the new feature to reach the users.  Shipping
> a few additional files in the /etc/profile.d directory would be a
> reasonable stopgap measure.
No, it would be totally broken as explained.
>> 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...?)
> That's a valid concern.  Perhaps some documentation could be provided,
> to help the users who alter their background colors.

Already documented in the iputils2 manpage and elsewhere.

>> And what about linux virtual terminals (a.k.a non-graphical consoles)?
>>
> In my 25+ years of Linux experience, I've never seen one with a
> background color other than black.

Which is why it's such a reasonable assumption for iputils2 to male.

(BTW I have seen non-black vt colors... just happens to be true. But not 
so common)

>> 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.
> As others already pointed out, "should be light" or "should be dark"
> can be seen as personal preference.

It can and should be seen as begging the question of what is more common 
in the reality out there.

The matter of personal preference is whether deep blue on black is a bad 
choice.

What is the more common background color is a question of fact, not 
preference. We don't get to have preferred facts. I just do not know how 
to find out what the fact is, so I must use reserved language and say I 
_think_ dark is more common.

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 15:19, Sirius wrote:
> In days of yore (Thu, 23 May 2024), Gedalya thus quoth:
>> 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.
> 
> Then it perhaps should not add colour to the output in the first place 
> and
> focus solely on the networking.
> 
> A suggestion would be the iproute2 package revert the option to compile
> colourised output as default, sticking to plain text output as that
> require zero assumptions about the user terminal. Carry on offering the
> '-c' switch to enable it at runtime.

Frankly, a better suggestion would be to leave that compile-time option
supported, but to suggest that it isn't used until the current issues 
are
resolved, or until some stopgap measures are in place.

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 9:23 PM, Dragan Simic wrote:
>> And what about linux virtual terminals (a.k.a non-graphical consoles)?
>
> In my 25+ years of Linux experience, I've never seen one with a 
> background
> color other than black. 

You kind of missed my question: Do we make a new rule where a correctly 
set COLORFGBG is mandatory for linux vt?

That's what I meant. The fact that both vt and graphical terminal 
emulators tend to be dark is another point.

My point is you can't rely on COLORFGBG. You can only use it if/when set.

A reasonable default is needed.

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 15:39, Gedalya wrote:
> On 5/23/24 9:23 PM, Dragan Simic wrote:
> 
>>> For what problem?
>>> Obviously, for the problem your patch attempts to solve.
> 
> When nothing is indicated and a genuine _guess_ must be made, or a
> _default_ should be set, should that be dark or light?
> This is not a coding question.

See, once something becomes de facto standard, or some kind of de facto
standard, it becomes quite hard to change it.  It's often required to
offer much greater flexibility instead of just changing it.

> All defaults should be good in some situations and bad in fewer 
> situations.
> Having a default does not preclude reducing the number of cases it is
> relied upon. Those are different matters.

Yes, but again, please see my point above.

>>>> If Debian configures the terminal emulators it ships to use dark
>>>> background,
>>> 
>>> Do they? Or is that the nearly universal default?
>> 
>> Frankly, I don't know for sure because I don't use many different
>> terminal emulators, but you as the submitter of this patch perhaps
>> should know that better.  However, terminal emulators must be
>> configured somehow, because it makes no sense whatsoever that they're
>> having their background colors hardcoded.
> 
> If you use the word "configure" to refer to the default behavior, set
> by upstream and not modified by the distribution, then fine, yes.
> 
> It's just a way of saying "terminals tend to be dark".

Actually, "configure" can be used for both purposes, i.e. for the
default upstream settings, and for some adjustments to those settings,
performed by the distributions.  For example, some distributions may
adjust the background color to use some darker shade of gray, which
may be easier on the eyes, instead of using pitch black background
that may be the upstream default.

Though, I don't know what each and every distribution does, or what
each and every upstream default is.

>>>> 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.
>> 
>> Of course, but that would take a lot of time, both to implement it
>> everywhere and for the new feature to reach the users.  Shipping
>> a few additional files in the /etc/profile.d directory would be a
>> reasonable stopgap measure.
> 
> No, it would be totally broken as explained.

It would be broken only for those users who change their background
color to some light color.  Though, it would be broken even with your
patch applied, right?  I see no difference in the end results, for the
users that reconfigure their terminals that way.

>>> And what about linux virtual terminals (a.k.a non-graphical 
>>> consoles)?
>>> 
>> In my 25+ years of Linux experience, I've never seen one with a
>> background color other than black.
> 
> Which is why it's such a reasonable assumption for iputils2 to male.
> 
> (BTW I have seen non-black vt colors... just happens to be true. But
> not so common)

I saw those on Solaris only.

>>> 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.
>> As others already pointed out, "should be light" or "should be dark"
>> can be seen as personal preference.
> 
> It can and should be seen as begging the question of what is more
> common in the reality out there.
> 
> The matter of personal preference is whether deep blue on black is a 
> bad choice.
> 
> What is the more common background color is a question of fact, not
> preference. We don't get to have preferred facts. I just do not know
> how to find out what the fact is, so I must use reserved language and
> say I _think_ dark is more common.

I see, and I do agree to a certain degree, but please see my point
about de facto standards.

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 15:50, Gedalya wrote:
> On 5/23/24 9:23 PM, Dragan Simic wrote:
>>> And what about linux virtual terminals (a.k.a non-graphical 
>>> consoles)?
>> 
>> In my 25+ years of Linux experience, I've never seen one with a 
>> background
>> color other than black.
> 
> You kind of missed my question: Do we make a new rule where a
> correctly set COLORFGBG is mandatory for linux vt?
> 
> That's what I meant. The fact that both vt and graphical terminal
> emulators tend to be dark is another point.
> 
> My point is you can't rely on COLORFGBG. You can only use it if/when 
> set.
> 
> A reasonable default is needed.

I think it would be best to start a gargantuan quest for having 
COLORFGBG
set properly for all kinds of different terminal emulators.  Including 
the
Linux virtual console, which may come last.

Re: iproute2: color output should assume dark background

[Sirius]

In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> On 5/23/24 9:23 PM, Dragan Simic wrote:
> > > And what about linux virtual terminals (a.k.a non-graphical consoles)?
> > 
> > In my 25+ years of Linux experience, I've never seen one with a
> > background
> > color other than black.
> 
> You kind of missed my question: Do we make a new rule where a correctly
> set COLORFGBG is mandatory for linux vt?
> 
> That's what I meant. The fact that both vt and graphical terminal
> emulators tend to be dark is another point.
> 
> My point is you can't rely on COLORFGBG. You can only use it if/when set.
> 
> A reasonable default is needed.

For the colours like blue and magenta, using \e[34;1m and \e[35;1m would
make it more readable against dark background. And testing with a dark
background right now, that would suffice the other colours are not
problematic to read. (It uses the "bright" version of the two colours
rather than the usual.)

That would be a miniscule change to iproute2 and would resolve the
problem no matter what background is used. I need to test with schemas
like solarized light and dark as well, as they are finicky.

-- 
Kind regards,

/S

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 10:02 PM, Dragan Simic wrote:
> See, once something becomes de facto standard, or some kind of de facto
> standard, it becomes quite hard to change it.  It's often required to
> offer much greater flexibility instead of just changing it.
>
Flexibility is offered by the COLORFGBG variable. The entire time we've 
been talking only about cases where that is not set.

Again, it is good to reduce to a minimum reliance on defaults. But aside 
from having a default the remaining option is to refuse to produce 
colors when COLORFGBG is not set, even when the user is explicitly 
asking for colors.

>>> everywhere and for the new feature to reach the users.  Shipping
>>> a few additional files in the /etc/profile.d directory would be a
>>> reasonable stopgap measure.
>>
>> No, it would be totally broken as explained.
>
> It would be broken only for those users who change their background
> color to some light color.  Though, it would be broken even with your
> patch applied, right?  I see no difference in the end results, for the
> users that reconfigure their terminals that way.
>
/etc/profile.d is shell session configuration.

If you want you can come up with shell magic that would set environment 
variables depending on which terminal environment the shell is running in.

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 10:07 PM, Dragan Simic wrote:
> I think it would be best to start a gargantuan quest for having COLORFGBG
> set properly for all kinds of different terminal emulators. Including the
> Linux virtual console, which may come last. 

And you'll still need a default and the default will at all times be 
_something_, and it being that something would be justified by.. well.. 
something?

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 10:11 PM, Sirius wrote:
> For the colours like blue and magenta, using \e[34;1m and \e[35;1m would
> make it more readable against dark background. And testing with a dark
> background right now, that would suffice the other colours are not
> problematic to read. (It uses the "bright" version of the two colours
> rather than the usual.)
>
> That would be a miniscule change to iproute2 and would resolve the
> problem no matter what background is used. I need to test with schemas
> like solarized light and dark as well, as they are finicky.

I find this constructive.

BTW I find that both current iproute2 palettes work with a light gray 
background.

It stands to reason that foreground colors could be chosen such that 
they work with black, several dark and several light background colors.

And yes please iproute2 should not be built with colors default-enabled!

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 16:11, Gedalya wrote:
> On 5/23/24 10:02 PM, Dragan Simic wrote:
>> See, once something becomes de facto standard, or some kind of de 
>> facto
>> standard, it becomes quite hard to change it.  It's often required to
>> offer much greater flexibility instead of just changing it.
>> 
> Flexibility is offered by the COLORFGBG variable. The entire time
> we've been talking only about cases where that is not set.

Yes, but the actual trouble is that COLORFGBG seems to be rarely set
automatically by the terminal emulators.

> Again, it is good to reduce to a minimum reliance on defaults. But
> aside from having a default the remaining option is to refuse to
> produce colors when COLORFGBG is not set, even when the user is
> explicitly asking for colors.

That's a very good proposal!  I'd highly support that behavior.

>>>> everywhere and for the new feature to reach the users.  Shipping
>>>> a few additional files in the /etc/profile.d directory would be a
>>>> reasonable stopgap measure.
>>> 
>>> No, it would be totally broken as explained.
>> 
>> It would be broken only for those users who change their background
>> color to some light color.  Though, it would be broken even with your
>> patch applied, right?  I see no difference in the end results, for the
>> users that reconfigure their terminals that way.
>> 
> /etc/profile.d is shell session configuration.
> 
> If you want you can come up with shell magic that would set
> environment variables depending on which terminal environment the
> shell is running in.

I had in mind setting COLORFGBG to dark background that way, not some
shell magic that would change it dynamically.

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 16:13, Gedalya wrote:
> On 5/23/24 10:07 PM, Dragan Simic wrote:
>> I think it would be best to start a gargantuan quest for having 
>> COLORFGBG
>> set properly for all kinds of different terminal emulators. Including 
>> the
>> Linux virtual console, which may come last.
> 
> And you'll still need a default and the default will at all times be
> _something_, and it being that something would be justified by..
> well.. something?

As you proposed a bit earlier, no COLORFGBG set would mean no coloring,
regardless of what the user requested.

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 16:19, Gedalya wrote:
> On 5/23/24 10:11 PM, Sirius wrote:
>> For the colours like blue and magenta, using \e[34;1m and \e[35;1m 
>> would
>> make it more readable against dark background. And testing with a dark
>> background right now, that would suffice the other colours are not
>> problematic to read. (It uses the "bright" version of the two colours
>> rather than the usual.)
>> 
>> That would be a miniscule change to iproute2 and would resolve the
>> problem no matter what background is used. I need to test with schemas
>> like solarized light and dark as well, as they are finicky.
> 
> I find this constructive.

Agreed, find such a balance would be a really good stopgap measure.

> BTW I find that both current iproute2 palettes work with a light gray
> background.
> 
> It stands to reason that foreground colors could be chosen such that
> they work with black, several dark and several light background
> colors.
> 
> And yes please iproute2 should not be built with colors 
> default-enabled!

Re: iproute2: color output should assume dark background

[Dragan Simic]

On 2024-05-23 16:28, Dragan Simic wrote:
> On 2024-05-23 16:19, Gedalya wrote:
>> On 5/23/24 10:11 PM, Sirius wrote:
>>> For the colours like blue and magenta, using \e[34;1m and \e[35;1m 
>>> would
>>> make it more readable against dark background. And testing with a 
>>> dark
>>> background right now, that would suffice the other colours are not
>>> problematic to read. (It uses the "bright" version of the two colours
>>> rather than the usual.)
>>> 
>>> That would be a miniscule change to iproute2 and would resolve the
>>> problem no matter what background is used. I need to test with 
>>> schemas
>>> like solarized light and dark as well, as they are finicky.
>> 
>> I find this constructive.
> 
> Agreed, find such a balance would be a really good stopgap measure.

Oops...  s/find/finding/

>> BTW I find that both current iproute2 palettes work with a light gray
>> background.
>> 
>> It stands to reason that foreground colors could be chosen such that
>> they work with black, several dark and several light background
>> colors.
>> 
>> And yes please iproute2 should not be built with colors 
>> default-enabled!

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 10:24 PM, Dragan Simic wrote:
> I had in mind setting COLORFGBG to dark background that way, not some
> shell magic that would change it dynamically. 

It's far far easier to just do color palette overrides in your terminal 
emulator.

The "Dark Pastels" preset in XFCE Terminal makes everything just work. 
Both iproute2 palettes work fine.

Anyone who really cares about colors can and should dive into the topic 
(not me). Once your graphical desktop is up and configured you'll be 
just fine.

The only real issue here is force-enabling colors where they are least 
welcome (crashed server, vt, no mouse, black background, just let me do 
my work please).

This entire discussion has gone way way way out of control.

Re: iproute2: color output should assume dark background

[Stephen Hemminger]

On Thu, 23 May 2024 22:33:03 +0800
Gedalya <gedalya@gedalya.net> wrote:

> On 5/23/24 10:24 PM, Dragan Simic wrote:
> > I had in mind setting COLORFGBG to dark background that way, not some
> > shell magic that would change it dynamically.   
> 
> It's far far easier to just do color palette overrides in your terminal 
> emulator.
> 
> The "Dark Pastels" preset in XFCE Terminal makes everything just work. 
> Both iproute2 palettes work fine.
> 
> Anyone who really cares about colors can and should dive into the topic 
> (not me). Once your graphical desktop is up and configured you'll be 
> just fine.
> 
> The only real issue here is force-enabling colors where they are least 
> welcome (crashed server, vt, no mouse, black background, just let me do 
> my work please).
> 
> This entire discussion has gone way way way out of control.

Fits perfect with "what color for the bike shed"

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/23/24 10:59 PM, Stephen Hemminger wrote:
> Fits perfect with "what color for the bike shed"

I'd love it if someone actually commented on my patch.

Currently, iproute2 does produce colored output when COLORFGBG is unset. 
If that remains unchanged:

         It selects a certain palette.

Does everyone here think that keeping the current selection best serves 
the majority of users?

It's a simple question.

It seems to me that it should revolve around a guesstimation of what 
background colors people are using. Or maybe I'm wrong.

No one is arguing here about what colors anyone _should_ be using. I 
also think it's misguided to regard an issue of unreadable output as 
trivial. Using a black background is something you can choose away from, 
except in an emergency, and not so much on vt. And navy blue on black is 
just hard to read. Poor contrast. If you can read that easier than 
others then fine, good for you, but this is about usability, it has 
literally nothing to do with personal taste.

-------

Alternative approaches: default to light bg, but select dark bg when 
TERM=linux (linux vt), I'd be happy to write the patch.

I'd like to try to alter the colors as suggested by Sirius, and if 
everyone agrees I'd like to also stick to defaulting to dark bg if not 
indicated otherwise.

RE: iproute2: color output should assume dark background

[David Laight]

From: Sirius
> Sent: 23 May 2024 14:20

> 
> In days of yore (Thu, 23 May 2024), Gedalya thus quoth:
> > 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.
> 
> Then it perhaps should not add colour to the output in the first place and
> focus solely on the networking.
> 
> A suggestion would be the iproute2 package revert the option to compile
> colourised output as default, sticking to plain text output as that
> require zero assumptions about the user terminal. Carry on offering the
> '-c' switch to enable it at runtime.

+42 :-)

An alias in .profile can add -c - leaving it easy to turn off.
Especially for those of us who get fed up of garish colours.
gdb is pretty impossible to use these days - blue on black ???
Syntax colouring in vi make the code look like paint has been
spilt on the page - wouldn't be too bad if it was subtle (and correct).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: iproute2: color output should assume dark background

[Gedalya]

On 5/28/24 5:07 PM, David Laight wrote:
> An alias in .profile can add -c - leaving it easy to turn off.
> Especially for those of us who get fed up of garish colours.
> gdb is pretty impossible to use these days - blue on black ???
> Syntax colouring in vi make the code look like paint has been
> spilt on the page - wouldn't be too bad if it was subtle (and correct).

Debian is enabling color by default in their build. That's not an upstream issue.

Comments belong here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071582

The --color=never option still works and you can set that in your profile, but we want it to work well out of the box.