[discussion] Should `NO_COLOR` fully cancel out the effect of `FORCE_COLOR`?

[webknjaz]

It looks like some projects (namely, Rich) start printing out things like bold/italic with FORCE_COLOR set (additionally to producing colors), but don't stop doing that when FORCE_COLOR=1 is also present. So it results in programs producing non-colored output with ANSI sequences in stdout. When that is piped into other programs, the supposedly machine-readable output is suddenly broken and stuff explodes.

So I'd like to ask if NO_COLOR should fully suppress the effect of FORCE_COLOR or not?

Cross-posted @ https://github.com/jcs/no_color/issues/267 (that issue tracker got disabled)

[donatj]

FORCE_COLOR / NO_COLOR are intended to affect colored output only and not other ANSII control codes. Other control codes should continue to work as designed.

The reason NO_COLOR came to be in the first place is because some people dislike colored output and want to be able to disable it at the shell profile level. They wouldn't want or expect for it to stop other things like animated progress bars and other fancy output from working correctly.

[webknjaz]

Aha! So treating FORCE_COLOR as "also enable font styling" isn't correct, right?

[webknjaz]

Is this something to document in the FAQ?

[donatj]

Hmm, you've got me pondering.

It's certainly a strange behaviour. I'm not sure it's my place to tell them not to though.

I think that might kind of be an area of undefined behaviour.

[webknjaz]

I would suggest calling it out as such, in the FAQ, then…

[donatj]

I'd be curious if the https://github.com/jcs/no_color/issues/267 people have anything to say on the topic before I definitively take any sort of stance.

[webknjaz]

Absolutely! It's a good idea to have coordinated semantics of both vars, since they're effectively solving different sides of the same use case…

cc @jcs

[webknjaz]

Do we need a no-ansi.org / NO_ANSI now? 😆

[webknjaz]

I'd be curious if the https://github.com/jcs/no_color/issues/267 people have anything to say on the topic before I definitively take any sort of stance.

UPD: it looks like @jcs disabled issues in that repository and so the issue URL returns 404 now. I haven't gotten any updates in the email before that happened, though.

@donatj sounds like it's time to make a stance, after all?

[worstpractice]

@donatj With sincere apologies for this unsolicited wall of text, I see (atleast) three potential approaches to tackling this problem.

1. Paradox in, paradox out

Paradoxical configurations will produce paradoxical outcomes.

I'm being told this is a feature and not a bug.

It is the sole responsibility of the end user not to express paradoxical preferences (e.g. simultaneously requesting NO_COLOR and FORCE_COLOR).

This is especially true if, as is reasonable to expect, the preferences of said end user include a strong preference against paradoxical outcomes in general.

With access to a time machine we could perhaps have "standardized" around a variable more akin to COLOR, which could then accept an enum of values, or indeed be absent altogether. But alas.

2. Interpreting FORCE_COLOR as the stronger of the two

Comparing the "specifications" (explainer texts) of NO_COLOR and FORCE_COLOR, I (very subjectively) get the clear impression FORCE_COLOR ought to win.

As the word 'force' might suggest, it comes across to me as the more imperative of the two.

While the common goal of both "standards" is the transfer of power from software authors to software users, to the best of my understanding, NO_COLOR is overtly intended to be overridable, while FORCE_COLOR is not.

These design choices are both valid approaches towards the same goal.

However, as far as their interaction goes, FORCE_COLOR reads (to me) as the more nuclear option.

3. Boolean scrying

The best thing to do in a situation like this is to throw code at it from out of left field.

Consider the following example code (which you can run right there on the TypeScript playground to output an inscrutable mess a line-by-line truth table exemplifying this approach 👍).

[webknjaz]

I'd interpret NO_COLOR as stronger. FORCE_COLOR is often set globally in CIs but some programs need to be told not to output ANSI (so that the output is machine-parseable) and for that, people tend to use NO_COLOR on specific app invocations. Imagine the platform wants to force color where it can but the user wants to disable it in their shell — wouldn't it be desirable to listen to the user?

[worstpractice]

I'd certainly agree that erring on the side of omitting color is (AFAICT) certainly the right way to go.

[nicholaswmin]

This should be closed as completed with a final decision.

FWIW I agree with the NO_COLOR taking precendence.