Re: thoughts on NO_COLOR

[Kaz Kylheku (Coreutils)]

On 2022-02-27 12:37, Pádraig Brady wrote:
> I just noticed some de facto treatment of the NO_COLOR env var.
> https://no-color.org/

These people are not system implementors; they should not be proposing
variables in a POSIX-reserved namespace.

The website provides no contact links whatsoever; they have walled
themselves in Github, and take pull requests as the only means of
communication.

This is not the way to do things if you want to promote a standard,
or to engage with the free software world.

I'm instantly opposed to this NO_COLOR on the above grounds, and think
it's an excellent idea to show opposition by making programs call
abort() when they find NO_COLOR to be set.

However, I do think it's a great idea for users who don't want
color to have a single place to turn it off.

> I was considering having ls --color=auto honor this, but then thought
> it is not actually needed in ls, since we give fine grained
> control over the colors / styles used.
>
> For example one might very well always want at least some 
> distinguishing
> of files and directories, with bold / bright etc.
> which can be achieved now with LS_COLORS.
>
> Or looking at it another way, ls is ubiquitous enough
> that it's probably already color configured as the user desires,

ls is almost certainly color configured the way the user's distro
desires, at least initially.

Clearly, the variable is aimed at people who don't find
things configured as they want by default, and who don't want to
go into individual programs or distro scripts to do that, but only
flip a single master switch.

> and having ls honor the less fine grained NO_COLOR flag,
> would result in less flexibility.

More knobs to tweak can never result in less flexibility.

Were you thinking of "perplexity"? ;)

Speaking of which, I can see someone pulling their hair out trying
to get color working, not realizing that something set a NO_COLOR
environment variable somewhere.