[Toybox] Question about --color

[enh]

On Mon, Aug 15, 2022 at 11:29 PM Rob Landley <rob at landley.net> wrote:

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

aren't build fixes the kind of thing that _should_ go into master, even
when you're working in another branch?

might be worth bringing up with florian weimer --- he was on one of the
bugs saying "we should fix this", but didn't have time right then and may
have forgotten? (he's very not like the glibc maintainer you're thinking
of; he's responsible for what coordination exists between different libcs,
for example. seems like a good guy.)


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

i don't think there is one color scheme that "just works". there might be
_two_ (one for light, one for dark), but most terminals no longer support
the escape sequences to query colors (or didn't last i checked), which is a
shame.


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

yeah, sorry about that. i do have a "better but still broken" one lying
around somewhere; i'd got just far enough to realize what the _next_
rewrite should do differently. (iirc, mainly "actually read a token at a
time and handle quoting in there, rather than ending up with hacks for
quoting everywhere and bugs you can't really fix without doing it
differently".)


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

didn't IRIX man pages use yellow? istr their top used a little bit of
yellow to good effect too? (of course, they could do that because only a
monster wouldn't use xwsh's beautiful defaults, which were a deep blue for
non-root and a slate grey for root shells. say what you like, there's never
been another Unix looked anything like as pretty as IRIX...)


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

one of the things you can do because you're a monolith is have a
$TOYBOX_COLOR or whatever.

fwiw, recent debian seems to have done this via _aliases_ in the default
.bashrc instead. which is weird to me, but at least they're easily deleted
any time i find myself on such a system (and changes i make don't affect
anyone else).


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220816/c88c4a2e/attachment.htm>