Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #84701 > unrolled thread

Bug#1088739: colors make ip's output unreadable

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1088739: colors make ip's output unreadable Harald Dunkel <harri@afaics.de> - 2024-11-30 11:00 +0100
    Bug#1088739: colors make ip's output unreadable Luca Boccassi <luca.boccassi@gmail.com> - 2024-11-30 12:50 +0100
      Re: Bug#1088739: colors make ip's output unreadable Harald Dunkel <harald.dunkel@aixigo.com> - 2024-12-02 12:20 +0100
        Re: Re: Bug#1088739: colors make ip's output unreadable Luca Boccassi <bluca@debian.org> - 2024-12-03 20:30 +0100
          Re: Bug#1088739: colors make ip's output unreadable Bjørn Mork <bjorn@mork.no> - 2024-12-03 21:00 +0100
      Re: Bug#1088739: colors make ip's output unreadable Harald Dunkel <harald.dunkel@aixigo.com> - 2024-12-02 12:40 +0100
      Bug#1088739: colors make ip's output unreadable Bastian Blank <waldi@debian.org> - 2024-12-21 15:50 +0100
        Bug#1088739: colors make ip's output unreadable Bastian Blank <waldi@debian.org> - 2025-01-02 11:20 +0100
        Bug#1088739: colors make ip's output unreadable Luca Boccassi <bluca@debian.org> - 2025-01-02 21:00 +0100
    Processed: Re: colors make ip's output unreadable "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-11-30 12:50 +0100
    Re: Bug#1088739: colors make ip's output unreadable Bjørn Mork <bjorn@mork.no> - 2024-11-30 14:50 +0100
    Processed: Re: Bug#1088739: colors make ip's output unreadable "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-12-21 15:50 +0100
    Processed: Re: Bug#1088739: colors make ip's output unreadable "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-01-02 21:00 +0100
    Bug#1088739: colors make ip's output unreadable Axel Scheepers <axel.scheepers76@gmail.com> - 2025-01-12 13:30 +0100
    Bug#1088739: colors make ip's output unreadable Harald Dunkel <harri@afaics.de> - 2025-03-18 09:20 +0100
    Bug#1088739: colors make ip's output unreadable "Oliver M. Schode" <oliver.schode@online.de> - 2025-03-19 14:10 +0100
      Bug#1088739: colors make ip's output unreadable Ben Hutchings <ben@decadent.org.uk> - 2025-03-26 17:10 +0100
        Bug#1088739: colors make ip's output unreadable Luca Boccassi <bluca@debian.org> - 2025-03-26 19:00 +0100
    Bug#1088739: [PATCH iproute2 1/2] color: Introduce and use default_color_opt() function Ben Hutchings <benh@debian.org> - 2025-03-19 23:00 +0100
      Bug#1088739: [PATCH iproute2 2/2] color: Handle NO_COLOR environment variable in default_color_opt() Ben Hutchings <benh@debian.org> - 2025-03-19 23:00 +0100
    Bug#1088739: [PATCH iproute2 0/2] Improve coloured text readability Ben Hutchings <benh@debian.org> - 2025-03-26 15:10 +0100
      Bug#1088739: [PATCH iproute2 2/2] color: Do not use dark blue in dark-background palette Ben Hutchings <benh@debian.org> - 2025-03-26 15:20 +0100
      Bug#1088739: [PATCH iproute2 1/2] color: Assume background is dark if unknown Ben Hutchings <benh@debian.org> - 2025-03-26 15:20 +0100
      Bug#1088739: [PATCH iproute2 0/2] Improve coloured text readability patchwork-bot+netdevbpf@kernel.org - 2025-04-06 19:20 +0200
    Bug#1088739: marked as done (colors make ip's output unreadable) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-04-06 21:20 +0200

Page 1 of 2  [1] 2  Next page →

#84701 — Bug#1088739: colors make ip's output unreadable

Package: iproute2
Version: 6.12.0-1

Blue on a black background is as impossible to read as yellow on
white. Obviously it is not reasonable to modify the foreground
color without taking the background color into accout. Could you
please make sure ip and the other tools in iproute2 produce a
readable output *by default*? 

AFAIU upstream's default is COLOR_OPT_NEVER, see commit
c31fd80a2268c0b1b77e1d65827003a2327315b8 . Sounds reasonable to
me.


Thank you very much
Harri

[toc] | [next] | [standalone]

#84704

Control: tags -1 wontfix
Control: close -1

On Sat, 30 Nov 2024 10:46:27 +0100 Harald Dunkel <harri@afaics.de> wrote:
> Package: iproute2
> Version: 6.12.0-1
>
> Blue on a black background is as impossible to read as yellow on
> white. Obviously it is not reasonable to modify the foreground
> color without taking the background color into accout. Could you
> please make sure ip and the other tools in iproute2 produce a
> readable output *by default*?

See the manpage, you can set COLORFGBG in your shell profile according
to your configuration.
There are no patches or color choices downstream, it's just what
upstream provides, so if you don't like their choice of a default,
please bring it up upstream, we will not carry out-of-tree patches to
customise something like this for one particular user, sorry.

See:

https://lore.kernel.org/netdev/E1s9rpA-00000006Jy7-18Q5@ws2.gedalya.net/
https://lore.kernel.org/netdev/173e0ec8-583a-4d5a-931f-81d08e43fe2b@gedalya.net/

Feel free to chime in those discussions.

> AFAIU upstream's default is COLOR_OPT_NEVER, see commit
> c31fd80a2268c0b1b77e1d65827003a2327315b8 . Sounds reasonable to
> me.

It sounds unreasonable to me, I like having colors in the output, it
makes it so much more readable. This is quite literally bike shedding.

[toc] | [prev] | [next] | [standalone]

#84719

Hi Luca,

I think it is inappropriate that you put your personal preferences
over usability in general. It is unreasonable to set a font color
without taking the background color into account.

My request is to go with upstream's default, giving a readable output
in general. If a user prefers to have colors, he is still free to
configure iproute2 in his private environment accordingly. Upstream
follows this good practice, so should Debian.


Regards

Harri

[toc] | [prev] | [next] | [standalone]

#84723

> I think it is inappropriate that you put your personal preferences
> over usability in general. It is unreasonable to set a font color
> without taking the background color into account.

I think it is inappropriate that you put your personal preferences over
usability in general. It is unreasonable to unset a font color for
everyone because of your personal, non-default choices of
desktop/terminal themes. If a user prefers not to have colors, he is
still free to configure iproute2 in his private environment
accordingly.

iproute2 produces dozens of lines of dense output, and color-coding
fields greatly enhances readability and usability in the general and
default cases.

> PS: The color=auto is set in Debian's control/rules file (overriding
> upstream's default), so what are you actually talking about?

I am actually talking about the original email, which is referring to
the choice of color for some field. Quoting verbatim:

> Blue on a black background is as impossible to read as yellow on
> white.

Whether to use blue or yellow or any other specific color for a
specific field is just how iproute2 is coded. If you want to have
specific fields use different specific colors, you'll need to propose
such changes upstream.

[toc] | [prev] | [next] | [standalone]

#84724

Luca Boccassi <bluca@debian.org> writes:

>> Blue on a black background is as impossible to read as yellow on
>> white.
>
> Whether to use blue or yellow or any other specific color for a
> specific field is just how iproute2 is coded. If you want to have
> specific fields use different specific colors, you'll need to propose
> such changes upstream.

Do you need a new bug report to understand that it is YOUR Debian
packaging the complaints are about?  Just say so, then. There's no need
to be rude. Again.

Or did you really want us to go to upstream with your claim that they
broke this?

Can do both.  No problem


Bjørn

[toc] | [prev] | [next] | [standalone]

#84720

On 2024-11-30 12:39:31, Luca Boccassi wrote:
> There are no patches or color choices downstream, it's just what
> upstream provides, so if you don't like their choice of a default,
> please bring it up upstream, we will not carry out-of-tree patches to
> customise something like this for one particular user, sorry.
> 
PS: The color=auto is set in Debian's control/rules file (overriding
upstream's default), so what are you actually talking about?

[toc] | [prev] | [next] | [standalone]

#84896

Control: tags -1 - wontfix
Control: reopen -1

Hi Luca

On Sat, Nov 30, 2024 at 11:39:31AM +0000, Luca Boccassi wrote:
> See the manpage, you can set COLORFGBG in your shell profile according
> to your configuration.
> There are no patches or color choices downstream, it's just what
> upstream provides, so if you don't like their choice of a default,
> please bring it up upstream, we will not carry out-of-tree patches to
> customise something like this for one particular user, sorry.

The rest of the Debian Kernel team, which is maintainer of this package,
talked about this and came ot the following conclusion: this bug nees to
be fixed.[1]

Enabling colors by default is a deviation from upstream.  Debian also
does not enable colors by default in other low level tools like ls or
grep.  In some cases, colors are enabled in default bash configs.

So please either
- restore the upstream default of color disabled by default, or
- use a better usable color scheme (yes, I know this is hard with how
  colors work on usual termionals).

Bastian

[1]: https://salsa.debian.org/kernel-team/meetings/-/wikis/20241218#minutes
-- 
Spock: We suffered 23 casualties in that attack, Captain.

[toc] | [prev] | [next] | [standalone]

#85005

Hi Luca

On Sat, Dec 21, 2024 at 03:36:03PM +0100, Bastian Blank wrote:
> So please either
> - restore the upstream default of color disabled by default, or
> - use a better usable color scheme (yes, I know this is hard with how
>   colors work on usual termionals).

Please acknowledge you received this.

Bastian

-- 
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
		-- Kirk, "The Ultimate Computer", stardate 4731.3

[toc] | [prev] | [next] | [standalone]

#85012

Control: tags -1 moreinfo

On Sat, 21 Dec 2024 at 14:36, Bastian Blank <waldi@debian.org> wrote:
> On Sat, Nov 30, 2024 at 11:39:31AM +0000, Luca Boccassi wrote:
> > See the manpage, you can set COLORFGBG in your shell profile according
> > to your configuration.
> > There are no patches or color choices downstream, it's just what
> > upstream provides, so if you don't like their choice of a default,
> > please bring it up upstream, we will not carry out-of-tree patches to
> > customise something like this for one particular user, sorry.
>
> The rest of the Debian Kernel team, which is maintainer of this package,
> talked about this and came ot the following conclusion: this bug nees to
> be fixed.[1]

If you wish to discuss iproute2 bugs/MRs/changes in the future, please
do so including me, as I am the maintainer and sole contributor of
this package. Thanks.

> Enabling colors by default is a deviation from upstream.  Debian also
> does not enable colors by default in other low level tools like ls or
> grep.  In some cases, colors are enabled in default bash configs.

This is explicitly configurable, so it can't really be defined as a
"deviation from upstream" - if it wasn't intended to be configurable,
it wouldn't be. It's normal for package builds to provide build time
configuration, and happens all the time, all over the place (including
in the kernel package, otherwise everything in debian/config would be
a 'deviation from upstream').
Other network command line tools such as resolvectl and networkctl
also enable colors by default on TTYs, so prior art is definitely
mixed and not one-sided. And AFAIK there are no explicit rules either
way.

> So please either
> - restore the upstream default of color disabled by default, or

Sorry, but as already mentioned in this bug, I disagree with this
request, as the output is _much_ clearer with colors. Those who don't
want this, can just trivially disable it, just like with networkctl
and others. The default should provide the maximum usability. Even
with a simple 2 IFs case, due to the density of textual information
reported by these commands, color-highlighting helps tremendously to
given prominence to the important information, so that they jump up to
the eye:

https://i.imgur.com/l46ifzN.png

This is even more true when there are many interfaces on a system.

> - use a better usable color scheme (yes, I know this is hard with how
>   colors work on usual termionals).

Sure, as already mentioned in this bug, the idea of changing the
scheme is fine, but someone needs to precisely say what does not work,
and what it should be changed to. Saying "I don't like colors" is not
actionable. Saying, for example, "using the color RED for the 'DOWN'
status of an interface is bad because of <X reason> and should be
changed to <Y color>", would be actionable, but it hasn't happened so
far. If such details were provided I'm sure we can work something out
with Stephen. So, what exactly should be changed, and to what?

[toc] | [prev] | [next] | [standalone]

#84705 — Processed: Re: colors make ip's output unreadable

Processing control commands:

> tags -1 wontfix
Bug #1088739 [iproute2] colors make ip's output unreadable
Added tag(s) wontfix.
> close -1
Bug #1088739 [iproute2] colors make ip's output unreadable
Marked Bug as done

-- 
1088739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088739
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#84707

Luca Boccassi <luca.boccassi@gmail.com> writes:

> There are no patches or color choices downstream, it's just what
> upstream provides,

You know very well that this is not true, as this bug report already
states.  The upstream default is "never".  You enabled "auto" and
thereby broke terminal output for anyone using a dark background.

Blaming this on upstream is ... (couldn't figure out a suitabled
adjective to put here which would comply with Debian rules).


Bjørn

[toc] | [prev] | [next] | [standalone]

#84895 — Processed: Re: Bug#1088739: colors make ip's output unreadable

Processing control commands:

> tags -1 - wontfix
Bug #1088739 {Done: Luca Boccassi <luca.boccassi@gmail.com>} [iproute2] colors make ip's output unreadable
Removed tag(s) wontfix.
> reopen -1
Bug #1088739 {Done: Luca Boccassi <luca.boccassi@gmail.com>} [iproute2] colors make ip's output unreadable
Bug reopened
Ignoring request to alter fixed versions of bug #1088739 to the same values previously set

-- 
1088739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088739
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#85011 — Processed: Re: Bug#1088739: colors make ip's output unreadable

Processing control commands:

> tags -1 moreinfo
Bug #1088739 [iproute2] colors make ip's output unreadable
Added tag(s) moreinfo.

-- 
1088739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088739
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#85102

Hello,

On Fri, 3 Jan 2025 21:00:38 +0100 Vincent Bernat <vincent@bernat.ch> wrote:
> On 2025-01-02 20:53, Luca Boccassi wrote:
> > Sorry, but as already mentioned in this bug, I disagree with this
> > request, as the output is_much_ clearer with colors. Those who don't
> > want this, can just trivially disable it, just like with networkctl
> > and others. The default should provide the maximum usability. Even
> > with a simple 2 IFs case, due to the density of textual information
> > reported by these commands, color-highlighting helps tremendously to
> > given prominence to the important information, so that they jump up to
> > the eye:
> >
> > https://i.imgur.com/l46ifzN.png
> >
> > This is even more true when there are many interfaces on a system.
>
> I don't find the dark blue on black very readable either, but this is
> more a terminal issue. In my terminal, I have a brighter blue that fits
> my needs.
>
> https://imgur.com/a/iFJEuV7
>
> Instead of trying to ask each program to modify their palettes, people
> could configure their terminals.

I'm hesitant to intervene because I know this is a controversial
topic. However, I'd like to bring to your attention that the usage of
colors in terminal output can be very hard to read for some (many?)
people. I have a lot of trouble reading colored output, be it to much
contrast or to little. Therefore personally I'd like to see color
usage as opt-in instead of opt-out. I have to keep a whole list of
aliases and environment variables to suppress color, each program has
it's own option which is borderline insane. I used to have set my
$TERM variable as either VT100 or xterm-mono to suppress colors but
with modern tools which just dump ansi without regard to the terminal
setting it's sad one has to do so much work to have a monochrome
terminal. My view is the system should be accessible in the default
setup. The usage of colors on the terminal is really hard to get right
for all and I think it's best to disable it and let the people who
want colors and can properly see them configure their terminal as they
want.

Kind regards,
Axel

[toc] | [prev] | [next] | [standalone]

#86492

Hi Luca,

any hope to get this resolved for Trixie? I would owe you a beer.

With kind regards
Harri

[toc] | [prev] | [next] | [standalone]

#86506

Package: iproute2
Version: 6.13.0-1
Followup-For: Bug #1088739

If it's wont-fix I guess the bug might as well be closed, or at least
denoted as it certainly isn't something we can't work around. That said
I find the request about as reasonable as it gets, nor are we talking
about mere matters of taste. On black background, which I still think
isn't too uncommon, the default is indeed unreadable. Nothing to argue
about. Then speaking of workarounds, I've been making do with an alias:
ip='ip -c=never'. Obviously far from optimal, maybe I could play around
with (another) environment variable that is only to do with colors,
those too are beginning to pile up. At least why it would have to be
blue, instead of say bright red, which is perfectly legible, I do not
quite understand.


Oliver

[toc] | [prev] | [next] | [standalone]

#86621

[Multipart message — attachments visible in raw view] — view raw

On Wed, 19 Mar 2025 13:50:14 +0100 "Oliver M. Schode"
<oliver.schode@online.de> wrote:
> Package: iproute2
> Version: 6.13.0-1
> Followup-For: Bug #1088739
> 
> If it's wont-fix I guess the bug might as well be closed, or at least
> denoted as it certainly isn't something we can't work around. That
said
> I find the request about as reasonable as it gets, nor are we talking
> about mere matters of taste. On black background, which I still think
> isn't too uncommon, the default is indeed unreadable. Nothing to argue
> about. Then speaking of workarounds, I've been making do with an
alias:
> ip='ip -c=never'. Obviously far from optimal, maybe I could play
around
> with (another) environment variable that is only to do with colors,
> those too are beginning to pile up. At least why it would have to be
> blue, instead of say bright red, which is perfectly legible, I do not
> quite understand.

Today's upload of version 6.14.0-1 adds support for the widely used
NO_COLOR environment variable.

I've sent some additional patches (to this bug report, and upstream)
which seem to improve the readability of coloured text in GNOME Terminal
and xterm with a dark background.  Those haven't yet been applied
anywhere.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                      - Albert Einstein

[toc] | [prev] | [next] | [standalone]

#86624

On Wed, 26 Mar 2025 at 16:09, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Wed, 19 Mar 2025 13:50:14 +0100 "Oliver M. Schode"
> <oliver.schode@online.de> wrote:
> > Package: iproute2
> > Version: 6.13.0-1
> > Followup-For: Bug #1088739
> >
> > If it's wont-fix I guess the bug might as well be closed, or at least
> > denoted as it certainly isn't something we can't work around. That
> said
> > I find the request about as reasonable as it gets, nor are we talking
> > about mere matters of taste. On black background, which I still think
> > isn't too uncommon, the default is indeed unreadable. Nothing to argue
> > about. Then speaking of workarounds, I've been making do with an
> alias:
> > ip='ip -c=never'. Obviously far from optimal, maybe I could play
> around
> > with (another) environment variable that is only to do with colors,
> > those too are beginning to pile up. At least why it would have to be
> > blue, instead of say bright red, which is perfectly legible, I do not
> > quite understand.
>
> Today's upload of version 6.14.0-1 adds support for the widely used
> NO_COLOR environment variable.
>
> I've sent some additional patches (to this bug report, and upstream)
> which seem to improve the readability of coloured text in GNOME Terminal
> and xterm with a dark background.  Those haven't yet been applied
> anywhere.

Very nice work, thanks for taking care of it! As soon as Steve/Dave
merge that series in main-next I'll backport it

[toc] | [prev] | [next] | [standalone]

#86511 — Bug#1088739: [PATCH iproute2 1/2] color: Introduce and use default_color_opt() function

[Multipart message — attachments visible in raw view] — view raw

As a preparatory step for supporting the NO_COLOR environment
variable, replace the direct use of CONF_COLOR with a
default_color_opt() function which initially returns CONF_COLOR.

Signed-off-by: Ben Hutchings <benh@debian.org>
---
 bridge/bridge.c | 2 +-
 include/color.h | 1 +
 ip/ip.c         | 2 +-
 lib/color.c     | 5 +++++
 tc/tc.c         | 2 +-
 5 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/bridge/bridge.c b/bridge/bridge.c
index f8b5646a..d993ba19 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -103,7 +103,7 @@ static int batch(const char *name)
 int
 main(int argc, char **argv)
 {
-	int color = CONF_COLOR;
+	int color = default_color_opt();
 
 	while (argc > 1) {
 		const char *opt = argv[1];
diff --git a/include/color.h b/include/color.h
index 17ec56f3..b543c267 100644
--- a/include/color.h
+++ b/include/color.h
@@ -20,6 +20,7 @@ enum color_opt {
 	COLOR_OPT_ALWAYS = 2
 };
 
+int default_color_opt(void);
 bool check_enable_color(int color, int json);
 bool matches_color(const char *arg, int *val);
 int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
diff --git a/ip/ip.c b/ip/ip.c
index c7151fbd..e4b71bde 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -166,7 +166,7 @@ int main(int argc, char **argv)
 	const char *libbpf_version;
 	char *batch_file = NULL;
 	char *basename;
-	int color = CONF_COLOR;
+	int color = default_color_opt();
 
 	/* to run vrf exec without root, capabilities might be set, drop them
 	 * if not needed as the first thing.
diff --git a/lib/color.c b/lib/color.c
index cd0f9f75..5c4cc329 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -81,6 +81,11 @@ static void enable_color(void)
 	set_color_palette();
 }
 
+int default_color_opt(void)
+{
+	return CONF_COLOR;
+}
+
 bool check_enable_color(int color, int json)
 {
 	if (json || color == COLOR_OPT_NEVER)
diff --git a/tc/tc.c b/tc/tc.c
index beb88111..0fc658c8 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -254,7 +254,7 @@ int main(int argc, char **argv)
 {
 	const char *libbpf_version;
 	char *batch_file = NULL;
-	int color = CONF_COLOR;
+	int color = default_color_opt();
 	int ret;
 
 	while (argc > 1) {

[toc] | [prev] | [next] | [standalone]

#86512 — Bug#1088739: [PATCH iproute2 2/2] color: Handle NO_COLOR environment variable in default_color_opt()

[Multipart message — attachments visible in raw view] — view raw

The NO_COLOR environment variable is a widely supported way for users
to disable coloured text output.  See <https://no-color.org/>.  In
case iproute2 is configured to use colours by default, allow this to
be overridden by setting NO_COLOR.

This is done in default_color_opt() so that colours can still be
explicitly enabled with a command-line option.

Signed-off-by: Ben Hutchings <benh@debian.org>
---
 lib/color.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lib/color.c b/lib/color.c
index 5c4cc329..3c6db08d 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -83,6 +83,13 @@ static void enable_color(void)
 
 int default_color_opt(void)
 {
+	const char *no_color;
+
+	/* If NO_COLOR has a non-empty value, coloured output is never wanted */
+	no_color = getenv("NO_COLOR");
+	if (no_color && *no_color)
+		return COLOR_OPT_NEVER;
+
 	return CONF_COLOR;
 }
 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web