Add ability to force disable colors with an environment variable #31

Qix- · 2015-09-02T19:25:24Z

So this extends the FORCE_COLOR environment variable to allow FORCE_COLOR=0 (preserving the behavior of just FORCE_COLOR=), which will forcibly disable color environment-wide.

This was inspired by the bug over at electron/electron#1647

sindresorhus · 2015-09-02T19:30:40Z

Wouldn't it be better to have a separate variable, like DISABLE_COLOR?

Qix- · 2015-09-02T19:38:43Z

I read FORCE_COLOR=0 as force color: off. More than one environment variable would be messy; what happens when both are 1?

silverwind · 2015-09-03T01:04:18Z

Wouldn't it be better to have a separate variable, like DISABLE_COLOR?

I'd advice not to use generic variable names like that. Something like CHALK_COLOR or even SUPPORTS_COLOR_ENABLE would make it more obvious where that variable belongs and avoid naming collisions with other software. But it's probably too late to change that now, is it?

Qix- · 2015-09-03T01:45:13Z

FORCE_COLOR was part of some ANSI movement a while back, which I think is why it's in there. I agree with @silverwind, even though I also think FORCE_COLOR=0 is sufficient, personally.

sshiman · 2016-01-05T14:31:03Z

Are the any plans to merge this pull request yet? Need this with regards to issues with PowerShell on Windows displaying Gulp output (using chalk). Need to disable coloring to workaround that issue. Checking on the value for FORCE_COLOR like FORCE_COLOR=0 will work from my opinion. Any ETA on releasing of this change?

Qix- · 2016-01-05T20:34:54Z

I think this PR looks fine and wouldn't mind merging it. @sindresorhus should have the final word.

sindresorhus · 2016-01-05T20:36:14Z

I thought #32 superseded this?

Qix- · 2016-01-05T20:45:40Z

Perhaps at one point. This could stand on its own, though. This seems more sane than introducing a new env variable. I would personally want to see this one before I saw the other one, and I think the other one could use some improvement whereas this one is good to go.

sshiman · 2016-01-05T21:04:47Z

I agree that no need to introduce the new variable right now. So, any ETA on merging?

jhasse · 2016-01-05T21:58:21Z

Actually I don't think this should be merged, as this introduces a new behavior which is unique to this package. Is there any documentation for the FORCE_COLOR variable besides this README? What if other programs rely on FORCE_COLOR=0?

I think a new variable might be best, maybe CLICOLOR_DISABLE?

sshiman · 2016-01-05T22:03:24Z

To my knowledge the value for FORCE_COLOR is ignored, so I don't think anybody is using this one. But we need to rely on value instead of just existence of the variable in order to do the "switch". Introduction of the new variable will add a lot of complexity to "sync" all those variables' values.

jbnicolai · 2016-01-05T22:08:40Z

@Qix- Apologies, bit late to the discussion, but I'm with @sindresorhus that this is confusing. I interpreted (and initially implemented) FORCE_COLOR as a boolean flag, i.e.: override everything, or just apply default behaviour.

I agree that similar behaviour like FORCE_NO_COLOR also has it's usecases, but I think separating that into two boolean flags (force-go, force-no) is easier.

Since the original flag name 'FORCE_COLOR' was chosen simply because we weren't aware for a better standard, I'm leaning towards #32 as well, and suggest we close this one. If there's a better standard than suggested in #32, let's discuss there. Thanks for the effort though!

Qix- · 2016-01-06T00:08:18Z

Totally disagree. Having two environment variables makes no sense. What happens in the following scenario? The outcome is unclear.

FORCE_NO_COLOR= FORCE_COLOR= some-ansi-program --color

whereas

FORCE_COLOR= some-ansi-program
# or
FORCE_COLOR=1 some-ansi-program

and

FORCE_COLOR=0 some-ansi-program

make perfect sense. This is also analogous to other programs I've seen using environment variables as boolean values (namely, make and cmake).

Environment variables shouldn't be used as a programming construct, they should be used as configurations. Throwing more crap into your environment only waters things down and I firmly believe in the long run it'll confuse people to have two variables.

With one, all we need in the docs is setting it to 0 forces no color.

With two, we'll instead need a whole truth table:

	`FORCE_COLOR` present	`FORCE_COLOR` not present
`FORCE_NO_COLOR` present	??	no color
`FORCE_NO_COLOR` not present	color	default?

jhasse · 2016-01-06T00:17:40Z

FORCE_NO_COLOR= FORCE_COLOR= some-ansi-program --color

I don't think this is a problem as there are cases like this anyway:

FORCE_COLOR=0 some-ansi-program --color

Meaning that we have unclear scenarios anyway, a new environment variable would just introduce some more :D

FORCE_COLOR=0 some-ansi-program

It would not be intuitive to me that this would never output color.

Qix- · 2016-01-06T00:21:29Z

But it's clear that FORCE means trump everything. It's clear from our docs and it's clear from context. Using FORCE_COLOR=0 with --color is pretty clear as to what happens.

jhasse · 2016-01-06T00:31:20Z

True. Okay you convinced me: I'm against adding a new env var.

Still not convinced about FORCE_COLOR=0 as I read it as "forcing colors isn't enabled" and not as "never display colors". I think

CLICOLOR=0 some-ansi-program

(as implemented by #34) makes more sense.

Qix- · 2016-01-06T00:37:42Z

Im all for renaming it whatever if it doesn't make sense. Functionally though I remain of the opinion it should be one var.

jhasse · 2016-01-06T00:46:37Z

Unfortunately one (boolean) variable doesn't suffice, as there are 3 cases: on, off, auto. The last case could be handled by the TERM variable, but its possible values are a mess. Programs like ansicon need a simple way to tell that they support 16 colors via ANSI escape codes.

Qix- · 2016-01-06T09:31:37Z

Shouldn't rely on the TERM var any more than we have to, unless we add termcap capabilities.

As for the auto portion, if the variable doesn't exist then do auto. Otherwise, use its value (or lack thereof) to determine what to force.

jhasse · 2016-01-06T14:26:49Z

As for the auto portion, if the variable doesn't exist then do auto. Otherwise, use its value (or lack thereof) to determine what to force.

That wouldn't work on Window's cmd.exe, since it doesn't support ANSI colors out of the box.

Qix- · 2016-01-06T21:29:10Z

@jhasse it works just fine now, what are you talking about? By default supports-color returns 1 (16 colors) on windows unless other flags are present or the environment variable is there.

Windows supports ANSI escapes thanks to LibUV, obviously only within the Node.js environment.

Barring renaming this variable, this is how it would work:

FORCE_COLOR not present in system.env: automatic
FORCE_COLOR= or FORCE_COLOR=1: force colors
FORCE_COLOR=0: force no colors

It literally cannot get any simpler than that. This is a cross platform way to do it.

jhasse · 2016-01-06T21:58:21Z

@Qix- As you said yourself this is only within the Node.js environment. I was hoping for an universal variable name, and the Mac tools are already using CLICOLOR(_FORCE).

Qix- · 2016-01-06T22:02:44Z

@jhasse

Barring renaming this variable

jhasse · 2016-01-06T22:08:35Z

Than it still stands that outside of the Node.js environment, cmd.exe doesn't support ANSI escape codes out of the box. Therefore programs shouldn't output them when the variable isn't defined.

Qix- · 2016-01-06T22:09:29Z

@jhasse I'm not sure what you mean by that. Will supports-color be used outside of a Node.js environment?

jhasse · 2016-01-06T22:13:15Z

No. I'm looking for variable names which wouldn't only be used by supports-color though. CLICOLOR_FORCE for example is used by Mac's cmd tools and CMake. I'm trying to get the ball rolling, so that one day, I only have to define one env variable in my CI and all programs output ANSI escape codes.

Qix- · 2016-05-31T08:49:37Z

I'm still a 'yes' for this, after giving it some time @sindresorhus. I've run into a multitude of situations where FORCE_COLOR=0 would have been nice and easy to use and understand.

Any more discussion on this is bikeshedding - if I'm defining environment variables just to exist I'm not going to be setting them to =0. Alternatively, if I see SOME_VAR=0 I'm going to assume it's being shut off in an explicit matter.

jhasse · 2016-05-31T08:56:43Z

Any more discussion on this is bikeshedding - if I'm defining environment variables just to exist I'm not going to be setting them to =0. Alternatively, if I see SOME_VAR=0 I'm going to assume it's being shut off in an explicit matter.

+1

In order to keep variable names which control ANSI colors to a minimum I still hope for CLICOLOR(_FORCE)=0 instead of FORCE_COLOR :)

Qix- · 2017-01-16T00:34:09Z

@sindresorhus

I would have preferred a binary behavior CLICOLOR=0 for off and CLICOLOR=1 for on, if nothing is set it would behave as normal.

You said it yourself. I'm still on board with this PR and would like to see some movement on it. I'm tempted to merge this PR at the moment since we've been sitting on it for so long and it's becoming a point of bike-shed at this point.

sindresorhus · 2017-01-21T10:48:13Z

index.js

-	supportLevel = 1;
+if ('FORCE_COLOR' in process.env) {
+	var forceColor = parseInt(process.env.FORCE_COLOR, 10);
+	supportLevel = forceColor === 0 ? 0 : supportLevel || 1;


Wrap supportLevel || 1 in parens to make the precedence clear.

sindresorhus · 2017-01-21T10:49:24Z

readme.md

@@ -44,7 +44,7 @@ The returned object specifies a level of support for color through a `.level` pr

 It obeys the `--color` and `--no-color` CLI flags.

-For situations where using `--color` is not possible, add an environment variable `FORCE_COLOR` with any value to force color. Trumps `--no-color`.
+For situations where using `--color` is not possible, add an environment variable `FORCE_COLOR` with any value to force color. If `FORCE_COLOR` is set to `0`, colors are force disabled. Trumps `--no-color` / color flags, respectively.


I think we should drop with any value, and instead say FORCE_COLOR=1 to force color, FORCE_COLOR=0 to force disable colors, and don't use it for auto-detection (for clarity).

I've re-worded that whole section.

sindresorhus · 2017-01-21T10:50:25Z

test.js

+	var result = requireUncached('./');
+	assert.equal(Boolean(result), true);
+	assert.equal(result.level, 2);
+});


For completeness, can you add a test for process.env.FORCE_COLOR = '1'; too?

sindresorhus · 2017-01-21T10:54:01Z

I've been thinking long and hard about this issue and I've decided to go with this solution. I really don't want to introduce another environment variable, and from looking through the proposals about CLICOLOR(_FORCE) on other issue tracker, the response is generally lukewarm: http://bixense.com/clicolors/#bug-reports We can reconsider adding support for CLICOLOR at a later point if it ends up getting more adoption, but I'm not a big fan of the proposal, so I don't intend on being the person to push it forward.

Qix- · 2017-01-21T22:47:09Z

@sindresorhus the requested changes have been made.

jhasse mentioned this pull request Sep 24, 2015

Use CLICOLOR and CLICOLOR_FORCE #32

Closed

jhasse added a commit to jhasse/supports-color that referenced this pull request Oct 22, 2015

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

ac01715

jhasse added a commit to jhasse/supports-color that referenced this pull request Oct 22, 2015

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

34ec21d

jhasse added a commit to jhasse/supports-color that referenced this pull request Oct 22, 2015

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

8aad3ad

jhasse added a commit to jhasse/supports-color that referenced this pull request Oct 22, 2015

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

9fee69f

jhasse added a commit to jhasse/supports-color that referenced this pull request Oct 27, 2015

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

79b8c29

jhasse added a commit to jhasse/supports-color that referenced this pull request Jan 5, 2016

Check for CLICOLOR and CLICOLOR_FORCE. Fixes chalk#31 and chalk#32.

db40abd

jbnicolai mentioned this pull request Jan 5, 2016

Check for CLICOLOR and CLICOLOR_FORCE. Fixes #31 and #32. #34

Closed

Qix- mentioned this pull request Aug 29, 2016

Disable chalk via an environment varaible chalk/chalk#125

Closed

Qix- mentioned this pull request Oct 13, 2016

Color disabled on Travis-CI? #41

Closed

sindresorhus changed the title ~~added ability to force disabling of all colors~~ Add ability to force disable colors with an environment variable Jan 21, 2017

sindresorhus requested changes Jan 21, 2017

View reviewed changes

Qix- and others added 2 commits January 21, 2017 14:42

added ability to force disabling of all colors

0d135b1

fix nits by sindre

b7d94de

Qix- force-pushed the forcecolor-off branch from d671a64 to b7d94de Compare January 21, 2017 22:46

sindresorhus approved these changes Jan 22, 2017

View reviewed changes

sindresorhus merged commit a6b8b6d into master Jan 22, 2017

sindresorhus deleted the forcecolor-off branch January 22, 2017 18:54

Qix- mentioned this pull request Oct 16, 2017

FORCE_COLOR=0 does *not* disable chalk/chalk#213

Closed

plroebuck mentioned this pull request Dec 28, 2018

Remove MOCHA_COLORS environment variable mochajs/mocha#3641

Closed

waseemahmad31 mentioned this pull request Jan 8, 2019

Removed MOCHA_COLORS environment variable mochajs/mocha#3665

Closed

jaraco mentioned this pull request Oct 5, 2022

🎨 Make the GHA log clean and colorized jaraco/skeleton#66

Merged

natemoo-re mentioned this pull request Aug 3, 2023

Ensure color contrast requirements are met in the CLI interface. withastro/astro#7905

Closed

1 task

Add ability to force disable colors with an environment variable #31

Add ability to force disable colors with an environment variable #31

Conversation

Qix- commented Sep 2, 2015

sindresorhus commented Sep 2, 2015

Qix- commented Sep 2, 2015

silverwind commented Sep 3, 2015

Qix- commented Sep 3, 2015

sshiman commented Jan 5, 2016

Qix- commented Jan 5, 2016

sindresorhus commented Jan 5, 2016

Qix- commented Jan 5, 2016

sshiman commented Jan 5, 2016

jhasse commented Jan 5, 2016

sshiman commented Jan 5, 2016

jbnicolai commented Jan 5, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented Jan 6, 2016

jhasse commented Jan 6, 2016

Qix- commented May 31, 2016 • edited Loading

jhasse commented May 31, 2016

Qix- commented Jan 16, 2017

sindresorhus Jan 21, 2017

Choose a reason for hiding this comment

sindresorhus Jan 21, 2017

Choose a reason for hiding this comment

Qix- Jan 21, 2017

Choose a reason for hiding this comment

sindresorhus Jan 21, 2017

Choose a reason for hiding this comment

sindresorhus commented Jan 21, 2017

Qix- commented Jan 21, 2017

Qix- commented May 31, 2016 •

edited

Loading