netdev - Re: iproute2: color output should assume dark background

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 May 2024 16:11:36 +0200
From: Sirius <sirius@...dheim.com>
To: Gedalya <gedalya@...alya.net>
Cc: Dragan Simic <dsimic@...jaro.org>, netdev@...r.kernel.org
Subject: Re: iproute2: color output should assume dark background

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