I read both of your replies. Thank you. Helpful as always! So just to clarify... it's a pretty safe assumption that the palette is the default xterm-color256 palette? Would that be nestled in the xterm source code by chance?
On Fri, Mar 27, 2020 at 02:48:20PM -0500, Bryan Christ wrote:
> I need advice as to handle LS_COLORS. IMO, it's an absolute nightmare.
> Instead of using
> SGR 38:2 and 48:2 variants (which allow you know what the desired color is)
> it use SGR 38:5 and 48:5 which indicate a specific color number. The
That depends on the particular system (the upstream source in coreutils
doesn't have any of that -- though it _does_ say that "vt100" does ANSI
colors).
On the other hand, coreutils has some documentation.
The packagers as a general rule don't bother to document anything
past checkin-comments.
> problem is, there's no real way to know what the color value is supposed to
> be. It might be possible to query the color values with color_content()
> but as was discussed here...
>
> https://lists.gnu.org/archive/html/bug-ncurses/2020-02/msg00001.html
>
> ...it's not guaranteed to work. It seems the fundamental problem is that
> LS_COLORS takes advantage of information known only to the terminal and
> whoever specified the color values. Am I missing something here?
I wouldn't give it that much credit. It's a hard-coded set of color
values, which happens to "work" for a default configuration.
Since it's hard-coded (and essentially copy/paste scripting),
one can just assume that the color palette is xterm's default palette.
--
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net
--
Bryan
<><