Re: thoughts on NO_COLOR

[Bob Proulx]

Pádraig Brady wrote:
> I just noticed some de facto treatment of the NO_COLOR env var.
> https://no-color.org/

I happened to run across this site myself a few weeks ago.  When I saw
it I had this immediate feeling of community.  Here was someone else
who also felt the oppression of endless flashing lights, ringing of
bells, and awful color choices being pushed upon us by default!  When
working on the computer I really don't want to feel like I am walking
through a casino.

I forwarded the site to another friend who was also was happy to see a
site with documentation as a resource for how to stop the noisy color
choices.  We agreed it was a useful resource because every program has
been set up to do this completely independently and differently.

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

Mostly I can always unset any alias that sets ls with --color.  This
one is so well known that it's an easy routine.

It's the other odd corners that one doesn't do very often that are
more problematic.  When "dmesg" started spraying me with colors then I
had to stop and spend time to figure out how to disable the noise.
Utilities such as that are not run into immediately.  And then when
they do get hit then it is a distraction at that time.  Others such as
a default vim is almost unusable due to the onslaught.

It's worse when one is not in their home environment.  Such as if I am
debugging some server, standing in a freezing datacenter floor, in a
limited environment, without all of my home customization.  That's
when some of these defaults are truly annoying.

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

Actually ls -F is pretty good.  That's all I use.

> Or looking at it another way, ls is ubiquitous enough
> that it's probably already color configured as the user desires,
> and having ls honor the less fine grained NO_COLOR flag,
> would result in less flexibility.

I think ls is ubiquitous enough that everyone has already learned how
to deal with it right up front.  For me usually \ls is enough.
Therefore it isn't as much of a concern for ls.  And so I am not going
to lobby for coreutils picking up NO_COLOR.  But if things were to get
worse then it could be a proposal I could get behind.

Bob