New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use CLICOLOR and CLICOLOR_FORCE #32

Closed
jhasse opened this Issue Sep 24, 2015 · 20 comments

Comments

Projects
None yet
4 participants
@jhasse
Copy link

jhasse commented Sep 24, 2015

Currently FORCE_COLOR is used to force color support. It would be great if we can agree upon some sort of standard for the name of this environment variable as many tools need something like this (e.g. compilers, build tools, ...) written in lots of different languages.

As this really bugs me (working with Jenkins and atom-build and still not seeing colored output even though it would work), I've written a page about it here: http://bixense.com/clicolors/

What do you think? With CLICOLOR=0 this would also fix #31.

@Qix-

This comment has been minimized.

Copy link
Member

Qix- commented Sep 24, 2015

I've seen a few of these "standards" pop up before; I don't know how I feel about supporting all of them. @sindresorhus what do you think?

@jhasse

This comment has been minimized.

Copy link

jhasse commented Sep 24, 2015

IMHO supporting all of them is wrong. Can you point me to some of the previous ones? I would love to get in contact with the other ones.

I have searched a lot and AFAIK mine is the only one someone has written down.

@sindresorhus

This comment has been minimized.

Copy link
Member

sindresorhus commented Sep 24, 2015

I'll need to think about it, but tbh not a big fan of the CLICOLOR != 0 behavior and the fact that there's two variables. 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.

@sindresorhus

This comment has been minimized.

Copy link
Member

sindresorhus commented Sep 24, 2015

Also:

image

@jhasse

This comment has been minimized.

Copy link

jhasse commented Sep 24, 2015

@sindresorhus CLICOLOR=0 and CLICOLOR=1 would need a third case: When ANSI colors are supported, but should only be outputted when the program isn't piped (which means isatty() returns true). And with a third value this would be magic numbers.

Regarding the xkcd comic: That's why my "standard" isn't a new one, I just wrote down what the OSX command line tools already follow.

@Qix-

This comment has been minimized.

Copy link
Member

Qix- commented Sep 24, 2015

What's wrong with sticking FORCE_COLOR=1 in your rc file? I mean is there a problem that is arising from this that needs to be addressed? Or is this just preferential?

@sindresorhus

This comment has been minimized.

Copy link
Member

sindresorhus commented Sep 24, 2015

When ANSI colors are supported, but should only be outputted when the program isn't piped (which means isatty() returns true).

This is default behavior. Why does it need an explicit flag?

@jhasse

This comment has been minimized.

Copy link

jhasse commented Sep 24, 2015

The problem is, that this is the first time I heard of a program that respects FORCE_COLOR. I work with scons, make, cmake, clang, gcc, jenkins, atom-build, sublime text, rust, julia, Django and several other tools and I can't easily tell all of them that I want ANSI colors.

I would also be fine with FORCE_COLOR=1, but I guess there are people who also need a way to disable colors (#31). FORCE_COLOR=0 could work.

@sindresorhus Not on Windows and not all terminals support ANSI colors.

@Qix-

This comment has been minimized.

Copy link
Member

Qix- commented Sep 24, 2015

@jhasse windows supports console colors just fine. isatty() is shimmed for such weird terminals on weird platforms, and an environment variable is not going to fix those edge case problems to begin with IMO.

@jhasse

This comment has been minimized.

Copy link

jhasse commented Sep 24, 2015

@Qix- Windows doesn't support ANSI colors (only with ANSICON). There are also MSYS and cygwin on Windows which DO support ANSI colors, but not Microsoft's Console API.

Sorry, I'm no native English speaker and don't really understand what "shimmed for" means in this context. Can you try to explain it in other words? Thanks :)

@Qix-

This comment has been minimized.

Copy link
Member

Qix- commented Sep 24, 2015

isatty() is usually implemented in a way that makes sense on the system Node is running on, even if it's not analogous to an underlying API call.


ANSI escapes aren't supported on Windows, no. Console colors are supported.

@sindresorhus

This comment has been minimized.

Copy link
Member

sindresorhus commented Oct 22, 2015

I've thought this over, and I'm fine with us supporting it. PR welcome. We should then document these and still support FORCE_COLOR for legacy, but undocument it.

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

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

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

@jhasse

This comment has been minimized.

Copy link

jhasse commented Oct 22, 2015

Thanks! :)

My PR implements this, the documentation part is still missing though.

@jbnicolai

This comment has been minimized.

Copy link
Member

jbnicolai commented Jan 5, 2016

I'm also in favor of this. See the PR itself for an actual discussion of the implementation.

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

@jhasse

This comment has been minimized.

Copy link

jhasse commented Jan 5, 2016

As @Qix- suggested, I've moved the CLICOLOR_FORCE check to the bottom to trump no-color.

@jbnicolai

This comment has been minimized.

Copy link
Member

jbnicolai commented Jan 5, 2016

Upon further reflection, I don't think I agree with a deviation of the current behaviour in the first place.

FORCE_COLOR makes sense, you're not in a TTY (e.g. it's part of a pipe command) but want to override this check because the final output will be in a TTY.

The opposite, e.g. FORCE_NO_COLOR, makes no sense to me. Colors are an opt-in feature only used if the TTY's ENV claims it does or the program decides to pretend it does anyway (e.g. --color=true). So the question is: why would you want to override behaviour the TTY claims it supports, or the user decide to pretend it supports anyway? I cannot imagine this being a problem.

@jhasse

This comment has been minimized.

Copy link

jhasse commented Jan 5, 2016

So the question is: why would you want to override behaviour the TTY claims it supports, or the user decide to pretend it supports anyway?

Probably as a work around, see this comment:

Need this with regards to issues with PowerShell on Windows displaying Gulp output (using chalk). Need to disable coloring to workaround that issue.

#31 (comment)

Also you might want to color the output of a child process without piping it. You'd set e.g. FORCE_NO_COLOR, echo the escape sequence for the color you want, then execute the command and finally echo the reset escape sequence.

@Qix-

This comment has been minimized.

Copy link
Member

Qix- commented Jan 6, 2016

@jhasse then why won't FORCE_COLOR=0, as in how #31 does it, work?

@jhasse

This comment has been minimized.

Copy link

jhasse commented Jan 6, 2016

@Qix- That would work. I thought @jbnicolai was asking why a way to disable colors via an env var was needed at all.

@sindresorhus

This comment has been minimized.

Copy link
Member

sindresorhus commented Jan 21, 2017

Closing in favor of #31.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment