<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 15, 2022 at 11:29 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/15/22 17:10, enh wrote:<br>
> On Sat, Aug 13, 2022 at 3:42 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
>     On 8/10/22 10:02, enh wrote:<br>
>     > i don't have a _technical_ reason, but i will say i've always hated `ls<br>
>     --color`<br>
>     > and the first thing i do on a new OS install is _delete_ those default<br>
>     aliases.<br>
>     ><br>
>     > (actually, trying to translate that into a technical reason: you can't ask<br>
>     > terminals what the rgb value for an ansi color is,<br>
> <br>
>     Do you know about the new 24-bit color escape sequences? I played with them a<br>
>     bit last year:<br>
> <br>
>       <a href="https://landley.net/notes-2021.html#06-10-2021" rel="noreferrer" target="_blank">https://landley.net/notes-2021.html#06-10-2021</a><br>
>     <<a href="https://landley.net/notes-2021.html#06-10-2021" rel="noreferrer" target="_blank">https://landley.net/notes-2021.html#06-10-2021</a>><br>
> <br>
>     It's printf("\e[38;2;%d;%d;%dm", red, green, blue); to set the foreground color<br>
>     (each is 0-255), and 48;2 instead of 38;2 to set the background color.<br>
> <br>
> yeah, i use them all the time in hobby projects. i have a very fetching tetris<br>
> for terminals, and a tty-based editor that looks remarkably like visual studio<br>
> code. (as you know, _starting_ things is easy. _finishing_ them is the hard<br>
> part. i have so many proof of concepts for "tty-based editor that feels like<br>
> it's from this century", but it's the second 80% that i never get round to.)<br>
<br>
I work based on momentum: starting is hard, but then I get the bit in my teeth<br>
and keep going unless yanked out of it (although nested bug report stacks do<br>
that rather effectively... Why did glibc happen again? Why are other packages<br>
NOT going "you could #include linux/fs.h and sys/mount.h for 15 years and<br>
suddenly a glibc "upgrade" broke that: this is clearly a glibc bug, tell the gnu<br>
idiots to stop polluting the namespace without an #ifdef... How is this now<br>
suddenly MY problem? Grr. Already fixed it in my branch I can't upload until the<br>
fact I've locally replaced diff.c doesn't inconvenience android. Working on it...)<br></blockquote><div><br></div><div>aren't build fixes the kind of thing that _should_ go into master, even when you're working in another branch?</div><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     > since i don't have any issues with red or green on a dark background in any<br>
>     > terminal i've used,<br>
> <br>
>     Except the most common kind of colorblindness is red/green. :)<br>
> <br>
> yeah, but like you said above, the main issue for non-colorblind folks is just<br>
> legibility... it's blues and magentas on dark, or cyans and yellows on light,<br>
> usually. (though since "yellow" is sometimes more of a brown to avoid the<br>
> legibility-on-light problem, it can cause legibility-on-dark problems!)<br>
<br>
I didn't invent this color scheme, and busybox copied it too...<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It would be nice if we DID have a standards body that meant something, but posix<br>
got hijacked long ago (although its failure mode of having large holes in it was<br>
probably the least bad way to fail), and then the Linux Foundation swallowed up<br>
the LSB effort and completely invalidated it to the point it stopped mattering<br>
at all years ago...<br>
<br>
We have de-facto standards based on "what people will accept". Unfortunately,<br>
Ubuntu and Red Hat seem to be competing for "dumbest technical decisions we can<br>
manage, brought to you by capitalist differentiation..." Sigh.<br>
<br>
>     In theory there's some environment variable that can provide a color mapping to<br>
>     override the defaults. In practice, the existence of the "dircolors" command is<br>
>     Peak Gnu. It ONLY sets the colors for ls, not any other command. I.E. their ls<br>
>     implementation has a whole supporting command to set an environment variable<br>
>     for it.<br>
> <br>
>     As an aside, the "apropos" command is meta-annoying because neither "apropos<br>
>     color" nor "apropos colors" mentions ls (it's not searching the CONTENTS of the<br>
>     man page, just some decription field), and the meta part is that apropos --help<br>
>     does not actually have a description line saying what the command DOES.<br>
> <br>
> (yeah, `man -K` -- versus `-k` for just the short descriptions -- ftw!)<br>
<br>
Nobody's touched man.c since 2019, I suppose I should cycle back around to<br>
looking at that again at some point. (I was cleaning it up and it did the moving<br>
target thing out from under me...)<br></blockquote><div><br></div><div>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".)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     "zgrep -wl color /usr/share/man/man1/*.gz" worked though: looks like ls, top,<br>
>     grep, diff, and dmesg in toybox so far. (Plus less -R and watch -c but that's<br>
>     not an a decision about WHICH colors to output.) The troff man page says it has<br>
>     an option to _disable_ color output, but what does it do with color when it's<br>
>     not disabled?)<br>
<br>
I have a todo item to figure out how to efficiently do zgrep/zless/zcmp and<br>
friends. Seems like there's a missing design element there somewhere...<br></blockquote><div><br></div><div>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...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     I note that in dmesg you already enabled color with no --color to switch it on<br>
>     and no obvious way to switch it off except piping it through cat, so my current<br>
>     pondering on this topic has precedent. I may not know what's "right" but I tend<br>
>     to want the behavior to be CONSISTENT (and if at all possible have a common<br>
>     implementation), and right now it's not...<br>
> <br>
> yeah, which probably shows that i'm usually on a dark background --- none of<br>
> those colors are problematic for me, and (perhaps more importantly) i actually<br>
> feel like i'm getting some value from that. similar to the git diff colors (even<br>
> if i'd like to have intra-line diff coloring!). whereas the ls colors? i have<br>
> never felt the need for that. (i also don't use -F, for example, though i could<br>
> understand having a trailing / on directories better than i could understand<br>
> colors.)<br>
> <br>
> i guess the directory colors are so offensive because they're utterly arbitrary.<br>
> if you can reasonably map to traffic light colors (like diff or dmesg), it's<br>
> probably okay? else "get off my lawn!"?<br>
<br>
Aesthetic issues have been the bane of open source development for decades:<br>
<br>
  <a href="https://landley.net/notes-2010.html#13-08-2010" rel="noreferrer" target="_blank">https://landley.net/notes-2010.html#13-08-2010</a><br>
<br>
Oddly enough, it wasn't as big a deal back before distributed internet<br>
collaboration, because for projects like binkleyterm the coders knew each other<br>
and even talked face to face. It's the "coordinating drive-by patches" style of<br>
development that really can't handle the absence of empirical tests to resolve<br>
disputes. You get a benevolent dictator for life making the aesthetic decisions,<br>
 or you get the lowest common denominator focus grouped to death.<br>
<br>
I miss the days we actually had sociologists usefully analyzing our development<br>
models...<br>
<br>
> (grep? not a fan, but it's not yet upset me enough to actually turn it off on<br>
> those machines that have it. but never helped me enough to turn it on on those<br>
> that don't.)<br>
<br>
I want consistency. I also want to be compatible with what's there. Sadly, these<br>
two are often directly in conflict...<br></blockquote><div><br></div><div>one of the things you can do because you're a monolith is have a $TOYBOX_COLOR or whatever.</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>