Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Respect $NO_COLOR variable #13

Closed
Sohalt opened this issue Feb 4, 2019 · 4 comments
Closed

Respect $NO_COLOR variable #13

Sohalt opened this issue Feb 4, 2019 · 4 comments

Comments

@Sohalt
Copy link

Sohalt commented Feb 4, 2019

It would be cool for termcolor to respect the NO_COLOR "standard", i.e. when $NO_COLOR is set, termcolor should not colorize the output, at least in auto mode. See https://no-color.org
@Sohalt Sohalt mentioned this issue Feb 4, 2019
Closed
@BurntSushi
Copy link
Owner

Having the discussion spread across two issues is really confusing. So I'm going to copy the comments from BurntSushi/ripgrep#1186 into here:

By @BurntSushi:

I think I'm OK with this in principle. It should be implemented in termcolor as parts of its "auto" mode.

I think I've historically not done this because it's not clear to me how widespread NO_COLOR usage actually is.

By @Sohalt:

Thanks, and sorry for not doing my research. I suspected ripgrep to use some library for colored terminal output and that would obviously be the better place to implement this. I've opened #13.
As for how widespread NO_COLOR usage is, I can't really say, but I don't see a big downside to not implementing it. The variable name is fairly specific and even if it is set, one can override it, i.e. turn on colors, on a per program basis.
You can probably close this issue, since it needs to be implemented in termcolor and the change will eventually show up in ripgrep, when dependencies are updated.

@BurntSushi
Copy link
Owner

but I don't see a big downside to not implementing it

I do. If it doesn't garner wide appeal, then we're likely stuck with it forever. Once you add support for something like this, it is very difficult to remove. Of course, there is a chicken and egg problem here.

Part of my hesitation to do this is that there has been a long time work around to this, which is to set TERM=dumb, and is something that termcolor recognizes. The NO_COLOR FAQ mentions this, but I don't find the answer compelling.

@Sohalt
Copy link
Author

Sohalt commented Feb 8, 2019

Ok, I get what you are saying. So let's just leave this issue around and see, if there is enough demand? People in support of the issue can just use the 👍 reaction on the issue to express their interest.

@BurntSushi
Copy link
Owner

I added support for this in #24.

The next release of ripgrep should have this as well. It's currently on master: BurntSushi/ripgrep@5a6e17f

@BurntSushi BurntSushi mentioned this issue May 2, 2021
Closed
wbolster added a commit to wbolster/termcolor that referenced this issue Sep 27, 2022
@wbolster
bug: respect NO_COLOR env var only if set to non-empty value
b0c3930 
The NO_COLOR environment variable should only be honoured if the value
is not empty. This means ‘export NO_COLOR=’ (or equivalent) can be used
to enable color again, which is useful in environments where env vars
can be added, but not unset, e.g. CI systems supporting env vars in YAML
config files.

Quoting the informal ‘spec’:

> Command-line software which adds ANSI color to its output by default
> should check for a NO_COLOR environment variable that, when present
> and not an empty string (regardless of its value), prevents the
> addition of ANSI color. – https://no-color.org/

See also BurntSushi#13.
@wbolster wbolster mentioned this issue Sep 27, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@BurntSushi @Sohalt