Zig honors the both the NO_COLOR and YES_COLOR environment variables.
The former is an internet standard (https://no-color.org/) but the latter is not. A search using google reported only Zig io/tty.zig and a few unrelated matches (like no_color as a function parameter).
Since YES_COLOR is not an internet standard, why Zig use YES_COLOR instead of ZIG_YES_COLOR?
Personally I think it is just the logical inverse of NO_COLOR.
From reading the link the NO_COLOR is the reaction to the problem of being flooded with unwanted colors.
But if the people who started defaulting to color had invented a YES_COLOR standard instead, that allows to opt in to colors, then the people who didn’t want colors would have never invented the NO_COLOR standard, because they wouldn’t have been annoyed by colors they don’t want.
I don’t really care either way, but having to state that you don’t want something seems counter intuitive, because stating/configuring what you do want seems more solution oriented, than having to state all the things that I don’t want.
Imagine buying a pizza and paying 30 bucks because you didn’t state not to include every possible extra ingredient.
So personally I think YES_COLOR makes more sense.
My issue is that an upper case environment variable without a namespace/prefix is usually a recognized standard, and YES_COLOR is not.
Is that the case? Isn’t it just that it starts out as something somebody does and eventually it becomes a quasi standard, because more and more people recognize it and then people start defining it as a standard?
Basically to me it seems more like those standards just grow organically and sometimes they may appear as if they were “properly established” before they were used, but from my personal observation it seems, that it is often the other way around.
Some groups may be more rigorous in defining ways of doing things, before just going ahead and doing it in some way. But to me it seems there are probably more, that just go ahead and do it the way they want to, which is fine by me.
The way I see it, standards are there to document established common practice, to make it easier to find these ways of doing things and also increase compatibility by people being aware of it.
But if you don’t have that established common practice first, then you are just inventing standards that nobody may end up using. By using things that aren’t standardized you basically vote for them to become a common practice and eventually if somebody cares enough about it, they will turn it into a standard.
Trying to define the standard first, feels like wanting to script reality: “you all will do this and we will make it common practice, obey my standard!”.
From that side it has a tyrannical vibe to it.
People will end up doing what they like, you can create a standard, but it only matters if it helps people and supports them in doing what they want to do, if it doesn’t, it will just be ignored.
I prefer the easy going vibe of: “lets see what happens and then just document what seemed helpful and sensible”.
That way nobody has to come up with some great standard waterfall style (needing to predict the future, being blamed if it is a bad standard), before people even got a chance to see how it works out in practice, instead people are just free to experiment and the things that seem to work can just be formalized then.
Looking for ways to disable Python history, I found that Python 3.13-dev added support for colors: 1. Command line and environment — Python 3.13.0b2 documentation.
It is similar to what is done in Zig, with the difference that FORCE_COLOR is used instead of YES_COLOR and that it also supports PYTHON_COLORS for controlling colors only for the Python interpreter.
Additionally, the document specifies the environment variables precedence.
Searching via Google I found that FORCE_COLOR, although seems to not have a written spec, is mentioned in multiple projects.
It is possible that the FORCE_COLOR environment variable was invented by colors.js and improved by chalk.
There is also Standard for ANSI Colors in Terminals with a different environment variable CLICOLOR_FORCE.
https://force-color.org/ was my attempt at creating a spec fwiw. FORCE_COLOR is reasonably common. I’m a little surprised you didn’t find it in your Googling as I’m seeing a decent bit of traffic
What I did not find was YES_COLOR, currently used by Zig.