[Toybox] Question about --color

[Rob Landley]

On 8/15/22 17:10, enh wrote:
> On Sat, Aug 13, 2022 at 3:42 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 8/10/22 10:02, enh wrote:
>     > i don't have a _technical_ reason, but i will say i've always hated `ls
>     --color`
>     > and the first thing i do on a new OS install is _delete_ those default
>     aliases.
>     >
>     > (actually, trying to translate that into a technical reason: you can't ask
>     > terminals what the rgb value for an ansi color is,
> 
>     Do you know about the new 24-bit color escape sequences? I played with them a
>     bit last year:
> 
>       https://landley.net/notes-2021.html#06-10-2021
>     <https://landley.net/notes-2021.html#06-10-2021>
> 
>     It's printf("\e[38;2;%d;%d;%dm", red, green, blue); to set the foreground color
>     (each is 0-255), and 48;2 instead of 38;2 to set the background color.
> 
> yeah, i use them all the time in hobby projects. i have a very fetching tetris
> for terminals, and a tty-based editor that looks remarkably like visual studio
> code. (as you know, _starting_ things is easy. _finishing_ them is the hard
> part. i have so many proof of concepts for "tty-based editor that feels like
> it's from this century", but it's the second 80% that i never get round to.)

I work based on momentum: starting is hard, but then I get the bit in my teeth
and keep going unless yanked out of it (although nested bug report stacks do
that rather effectively... Why did glibc happen again? Why are other packages
NOT going "you could #include linux/fs.h and sys/mount.h for 15 years and
suddenly a glibc "upgrade" broke that: this is clearly a glibc bug, tell the gnu
idiots to stop polluting the namespace without an #ifdef... How is this now
suddenly MY problem? Grr. Already fixed it in my branch I can't upload until the
fact I've locally replaced diff.c doesn't inconvenience android. Working on it...)

>     > since i don't have any issues with red or green on a dark background in any
>     > terminal i've used,
> 
>     Except the most common kind of colorblindness is red/green. :)
> 
> yeah, but like you said above, the main issue for non-colorblind folks is just
> legibility... it's blues and magentas on dark, or cyans and yellows on light,
> usually. (though since "yellow" is sometimes more of a brown to avoid the
> legibility-on-light problem, it can cause legibility-on-dark problems!)

I didn't invent this color scheme, and busybox copied it too...

It would be nice if we DID have a standards body that meant something, but posix
got hijacked long ago (although its failure mode of having large holes in it was
probably the least bad way to fail), and then the Linux Foundation swallowed up
the LSB effort and completely invalidated it to the point it stopped mattering
at all years ago...

We have de-facto standards based on "what people will accept". Unfortunately,
Ubuntu and Red Hat seem to be competing for "dumbest technical decisions we can
manage, brought to you by capitalist differentiation..." Sigh.

>     In theory there's some environment variable that can provide a color mapping to
>     override the defaults. In practice, the existence of the "dircolors" command is
>     Peak Gnu. It ONLY sets the colors for ls, not any other command. I.E. their ls
>     implementation has a whole supporting command to set an environment variable
>     for it.
> 
>     As an aside, the "apropos" command is meta-annoying because neither "apropos
>     color" nor "apropos colors" mentions ls (it's not searching the CONTENTS of the
>     man page, just some decription field), and the meta part is that apropos --help
>     does not actually have a description line saying what the command DOES.
> 
> (yeah, `man -K` -- versus `-k` for just the short descriptions -- ftw!)

Nobody's touched man.c since 2019, I suppose I should cycle back around to
looking at that again at some point. (I was cleaning it up and it did the moving
target thing out from under me...)
 
>     "zgrep -wl color /usr/share/man/man1/*.gz" worked though: looks like ls, top,
>     grep, diff, and dmesg in toybox so far. (Plus less -R and watch -c but that's
>     not an a decision about WHICH colors to output.) The troff man page says it has
>     an option to _disable_ color output, but what does it do with color when it's
>     not disabled?)

I have a todo item to figure out how to efficiently do zgrep/zless/zcmp and
friends. Seems like there's a missing design element there somewhere...

>     I note that in dmesg you already enabled color with no --color to switch it on
>     and no obvious way to switch it off except piping it through cat, so my current
>     pondering on this topic has precedent. I may not know what's "right" but I tend
>     to want the behavior to be CONSISTENT (and if at all possible have a common
>     implementation), and right now it's not...
> 
> yeah, which probably shows that i'm usually on a dark background --- none of
> those colors are problematic for me, and (perhaps more importantly) i actually
> feel like i'm getting some value from that. similar to the git diff colors (even
> if i'd like to have intra-line diff coloring!). whereas the ls colors? i have
> never felt the need for that. (i also don't use -F, for example, though i could
> understand having a trailing / on directories better than i could understand
> colors.)
> 
> i guess the directory colors are so offensive because they're utterly arbitrary.
> if you can reasonably map to traffic light colors (like diff or dmesg), it's
> probably okay? else "get off my lawn!"?

Aesthetic issues have been the bane of open source development for decades:

  https://landley.net/notes-2010.html#13-08-2010

Oddly enough, it wasn't as big a deal back before distributed internet
collaboration, because for projects like binkleyterm the coders knew each other
and even talked face to face. It's the "coordinating drive-by patches" style of
development that really can't handle the absence of empirical tests to resolve
disputes. You get a benevolent dictator for life making the aesthetic decisions,
 or you get the lowest common denominator focus grouped to death.

I miss the days we actually had sociologists usefully analyzing our development
models...

> (grep? not a fan, but it's not yet upset me enough to actually turn it off on
> those machines that have it. but never helped me enough to turn it on on those
> that don't.)

I want consistency. I also want to be compatible with what's there. Sadly, these
two are often directly in conflict...

Rob