17 ms·

No_color

466 points by ducaale 5y ago

dspillett 5y ago
Submitted a few times in recent year. https://news.ycombinator.com/item?id=21171274 https://news.ycombinator.com/item?id=21171274 is the only one I can see, after a very cursory search, that got any discussion going at all.
blindmute 5y ago
>I want to use weird terminal themes that don't visually work well with most programs >therefore every single program must modify itself to accommodate me Uhhh, nope?
labster 5y ago
Title is incorrect. It should be NO_COLOR in all caps, like the environment variable.
- roryokane 5y ago
  Maybe Hacker News automatically recapitalized the title. It would make sense if it tries to forbid clickbaity titles like "ExampleDB, a POWERFUL NEW DATABASE".
gregmac 5y ago
> Why not just set $TERM to dumb or xterm without color support? Or change all color definitions in the terminal to print the same color? > The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown. I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. I respect others like no color (and there's already a solution per that, above), but I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale? Normally I wouldn't care, -- individual preferences are like opinions and everyone is entitled to their own -- but this imposes work on every developer/application. There's certainly ways to implement this that minimize impact, but it's still a non-zero up-front and ongoing maintenance/testing cost.
- eterevsky 5y ago
  There can be situations where the output intended for an ANSI terminal is shown as a raw text, including the color control sequences. Being able to switch off color should help with these situations.
- twic 5y ago
  > I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. There's a few programs i use where the colours were clearly chosen to work on a dark theme terminal. I use a light theme terminal, and they're illegible. I suppose the real problem here is that the output is tagged with physical colour, rather than some kind of semantic label which could be mapped to a colour in terminal configuration. But it's probably too late to do anything about that.
  - edflsafoiewq 5y ago
    IME most programs still use the 8 traditional ANSI colors, which are exactly that (labels mapped to actual colors through config).
    - ncenvr 5y ago
      The problem here is that the 8 (or 16) ANSI colors are labels for just that: colors. 0 for black, 1 for red, etc. What OP is suggesting is more "abstract" labels, probably like "error" or "warning". More akin to text editor themes, which assign colors to particular semantic groups.
      - edflsafoiewq 5y ago
        The labels are abstract. You can make them whatever color you want. Basically every terminal theme does this.
        nick__m 5y ago
scandox 5y ago
How generally are people dealing with these coloured logs when ingesting them into a centralized logging system? Is there much overhead in stripping these sort of things out.
- jagger27 5y ago
  Most of the time they’re not printed out at all because of isatty in underlying libraries. Centralized logging doesn’t usually go through a TTY.
  - noitpmeder 5y ago
    This is the correct answer (or at least it should be). Only print colors when going to a TTY, not when writing logs to a file.
- sverhagen 5y ago
  I think that in some cases you end up capturing the control codes that control these colors, so then you want to disable the colored output explicitly.
- hedora 5y ago
  I think state of the art is to add a json output mode, then berate people that complain that neither option is ergonomic if you actually need to read production logs.
- cyral 5y ago
  I reported this issue four years ago to Google Cloud (not sure if it was ever fixed, no updates to the report), as they don't stripe out ANSI color codes nor render them, so our logs in their log viewer were full of gibberish from any colored messages.
bin_bash 5y ago
While this is a good standard, I often find myself just doing `somecommand | cat` whenever I want to get rid of colors. Usually they're disabled when outputting to a non-tty device.
jagger27 5y ago
Definitely adding this to my todo list to add to the CLI tools I help maintain. A lot of modern tools add emojis to output as well, which I sometimes find unnecessary in a similar way to terminal colours. NO_COLOR and NO_EMOJI seem reasonable. Any other ideas?
rsync 5y ago
I think this is a fine idea but I wonder about this part: "... should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color ..." How common is this behavior ? That is, the presence of the env var regardless of its value trips the conditional ? That seems like asking for trouble / confusion ... especially since there is a very well understood practice of setting 0/1 false/true for settings like this. Is this commonly done and I have just never noticed it ?
- quesera 5y ago
  I think it's fairly common. NO_COLOR=1 NO_COLOR=true NO_COLOR=yes Rather than parsing all the permutations, the usual evaluation of env vars that are expected to hold a boolean type is just the equivalent of: #ifdef NO_COLOR
  - Monory 5y ago
    Well, in ZSH [[ -v VAR ]] can actually differentiate between unset and null variables And NO_COLOR= would lead to an non-intuitive behavior
    - Aeolun 5y ago
      I think the implication is that it should have a value.
- chrisseaton 5y ago
  > That is, the presence of the env var regardless of its value trips the conditional ? Pretty normal, yeah. You can `unset FOO` a variable to set it to false.
- scatters 5y ago
  It makes the logic simple in C (where the empty string is truthy); you can just write `if (getenv("FOO"))`.
alrs 5y ago
For tools that don't honor NO_COLOR, I have a filter called nofun, which gets rid of color and animations. https://github.com/alrs/nofun https://github.com/alrs/nofun
- dijonman2 5y ago
  You can also use col -bx
  - alrs 5y ago
    Neat. col -bx leaves more artifacts lying around, but it does get the job done.
- spicybright 5y ago
  I hope the author of the article sees this, because this is absolutely the best solution to what they want to do. I'm sure you can even do some clever bash-foo to run your term sessions through it, like how screen or tmux work.
  - viraptor 5y ago
    It works on stdout when using a pipe output, but it won't work with interactive apps using rich terminal capabilities and ncurses.
    - geophertz 5y ago
      What would prevent it from working with ncurses programs?
- jart 5y ago
  You can also pipe it through sed 's/\x1b\[[;0-9]*m//g'
  - Qub3d 5y ago
    As noted in the repo README: > One could do this with GNU sed, but developers working in proprietary operating systems don't have GNU sed.
styfle 5y ago
I usually need the opposite, FORCE_COLOR=1, when non-TTY is detected but I still want colors.
- layer8 5y ago
  Many(?) tools support --color=always.
- jhasse 5y ago
  https://bixense.com/clicolors https://bixense.com/clicolors
Taniwha 5y ago
Oh yes! I am so over programs that output yellow text into a terminal with a white background and somehow expect people to be able to read the result
- lolinder 5y ago
  Don't most terminal themes map colors such that they're all mostly legible? And if not, wouldn't it be trivial to change yellow to an orange or brown? As a rule, I don't see any reason why a terminal theme should have any color that is illegible on its background. That feels like a problem with the theme more than with the program running on it.
  - dahfizz 5y ago
    The exception is "true color" output[1]. In supported terminals you can make text any rgb value, regardless of theme. [1] https://gist.github.com/XVilka/8346728 https://gist.github.com/XVilka/8346728
    - lolinder 5y ago
      Fair. But presumably if you're doing that you're also specifying a good background color.
      - kevincox 5y ago
        You should? Yes. You are? Likely not. Developers will pick coliurs that look good on their theme and not even think about overriding the background colour until they get a bug report.
- heavyset_go 5y ago
  My pet peeve is purple and dark blue on black or gray backgrounds.
throwaway984393 5y ago
I wrote a shell script some time back that stripped ansi color from piped output. Haven't needed it since, but can't be hard to make again. So probably we don't need this kind of quasi-standard. (what's up with all the non-IETF "standards" all over HN and GitHub? there is an open standards process for technology, people. is the problem that us old folks never taught the youngsters how to make them?)
tomrod 5y ago
> While some developers and users obviously prefer seeing these colors, many users don’t. This is bold. (Pun intended). Colors are immensely beneficial for opt-in. I haven't heard very many complaints about it -- why does the author assume many users don't?
- layer8 5y ago
  Many doesn’t mean most, just a non-insignificant minority.
  - tomrod 5y ago
    Ah, it's a weasel word -- an assertion that takes 10X the amount of effort to disprove than to make. Got it.
  - mynameisash 5y ago
    I think the context here is trying to imply most: "While some developers ..., many users don’t." It's that 'many' is comparative to 'some' here.
    - tomrod 5y ago
      You hit the nail on the head. Until this thread, I've never heard complaints from developers I've worked with regarding terminal colors. I agree with the few comments that mention a fixed coloring on white background being miserable is a common-enough edge case that I hadn't considered before now (I've met two developers out of thousands who use light mode instead of dark mode, so my prior expectations were low).
- jiggawatts 5y ago
  ... but which colours? Windows terminals mercifully had simply white-on-black for decades, but thanks to the various Azure and .NET Core teams, Microsoft has been invaded by Linux and Mac users. Now everything has to be CoLoUr all the time. Random colours. Colours that make no sense. RED ERRORS that are actually just titles. GREEN OKAY that's actually just a table header. Etc... I had the misfortune of being forced to use some Node and NPM tooling recently, having come from Visual Studio and C# programming. It was strangely nostalgic, like... stepping back in time to the 1990s and almost childish user interfaces. The spinning |/-\ symbols (with colours!) just killed me. I hadn't seen those since DOS 6. There's something perversely conservative about Linux. There's all this talk of how it's the best development environment, but to me all this "colors in the terminal" stuff just seems like a throwback to the days when I had a 486...
systemvoltage 5y ago
Unrelated but is there a standard that keeps my ~/ home directory clean? I don't want billion apps to write ~/.foo_software_config to my home dir. It is a complete mess.
- loeg 5y ago
  Nowadays well-behaved apps tend to use a single file or directory under ~/.config/. I believe it is a FreeDesktop.org standard: https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html https://specifications.freedesktop.org/basedir-spec/latest/a...
  - ziml77 5y ago
    And on Windows that has just made the mess even worse. Applications writing to %USERPROFILE%\Documents, %APPDATA%, %LOCALAPPDATA%, %USERPROFILE%, and %USERPROFILE%\.config Every language needs something like this library as part of the standard library https://pypi.org/project/appdirs/ https://pypi.org/project/appdirs/ It would at least make it a little more likely that files end up where they should.
- sneak 5y ago
  XDG I believe is the name of the standard. https://wiki.debian.org/XDGBaseDirectorySpecification https://wiki.debian.org/XDGBaseDirectorySpecification
- cturtle 5y ago
  Yep, the XDG Base Directory specification [0]. Specifically the $XDG_CONFIG_HOME variable. [0]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
  - samesamebutsame 5y ago
    The few things I have written always have the configs in here, seems like the polite thing to do without cluttering up home for the end user, but I can't help laugh when I look my own system and apps are storing gigabytes of data in there. It's not really a config folder anymore, more a misused general store for files.
deleted 5y ago
[deleted]
cturtle 5y ago
One question this leaves me with is regarding other ANSI escapes. Would a user with NO_COLOR be okay with bold, invert, italic, underline, or other effects? I’m happy to add support for NO_COLOR to the tool I maintain, but I think this proposal should be more clear in this regard. I would assume that COLOR implies that only color escapes should be disabled, but the description also mentions “plain” output.
- lokedhs 5y ago
  This problem was solved using the TERM environment variable, and it will just work when people use terminfo (and libraries that use it, such as ncurses). The problem is when people use explicit escape codes in their code rather than using libraries that solved this problem all the way back in the 80's. Yes, I'm somewhat grumpy about this because far too many times I have found log files filled with escape codes, or colours that are absolutely unreadable when using a terminal with white background.
drewg123 5y ago
What drives me insane is the UEFI shell using dark blue text for some things. That's impossible to read with a black background. The last place I want to squint and guess at what something says is when I'm applying a firmware update via a uefi tool, or un-foobaring a bootloader..
brandonbloom 5y ago
Competing standard for CLICOLOR and CLICOLOR_FORCE variables that have some support: https://bixense.com/clicolors/ https://bixense.com/clicolors/
- IshKebab 5y ago
  Yeah this is the earlier and better standard (more powerful and more precedent). The NO_COLOR guy should have dropped it as soon as people told him about this but now we have a stupid competing standards situation. If you support NO_COLOR you're making things worse.
TedShiller 5y ago
Part of the reason I avoid npm
dathinab 5y ago
> many users don’t. I doubt the "many" parts. It sooo much more readable if your program outputs a lot of data. And any (proper) implementation automatically switches the escape codes of if piping to another program instead of terminal so it rarely causes problems. I'm sure there are still some people which do not like it, and there are some libraries which mess up colors without doubt. So I'm fully in support of NO_COLOR as a "de-facto" standard.
tentacleuno 5y ago
This is the type of thing that should be supported in higher-level libraries like Chalk[0] (maybe it is?). We all know that Joe Bloggs' CLI isn't going to be checking for NO_COLOR. [0]: https://www.npmjs.com/package/chalk https://www.npmjs.com/package/chalk
- aendruk 5y ago
  The linked page lists thirty of them. Chalk isn’t on the list, but it used to be: https://github.com/jcs/no_color/commit/98857d0 https://github.com/jcs/no_color/commit/98857d0
somecommit 5y ago
- spicybright 5y ago
  I get what you mean, but you're not adding much to the discussion. I think of a few reasons you'd want to disable color that aren't for pure aesthetics: - Visually impaired users might have trouble with a lot of colors - Fully blind users won't see the color, so if it ties into a core feature of the tool, a NO_COLOR flag would force the developer to address it. For the record, I think the article OP linked to is pretty stupid in general, but I like playing devils advocate.
- gkbrk 5y ago
  If someone else becoming happy when their tools suit them better bothers you so much, maybe you should consider seeing one yourself.
ziml77 5y ago
I think it's reasonable to want an easy way to disable colored output, but I don't get why TERM doesn't work. Unless the request here is not for no colors but instead for fewer colors. But if it's to disable all colors in applications, then I believe changing TERM should work. And if you run something that you want colored you can override TERM for that process.
- tadfisher 5y ago
  TERM is a rather blunt instrument which changes support for many features besides ANSI color. SSH sessions further complicate matters. TERM=dumb is useful for cases where you absolutely want serialized output, such as CI logging. Interactive cases require you to choose a value that both your terminal emulator and the software supports.
  - ziml77 5y ago
    I didn't know about TERM=dumb at all until last weekend when I was messing with Haskell. Without it, the line editor in the REPL was broken when moving through the history (in both Terminal.app and iTerm2). I was surprised that it worked though since I expected that TERM=dumb would result in the REPL not being able to use any ANSI escape codes.
atommclain 5y ago
Conversely if you want to add color to a command, I have found Generic Colorizer to be useful: https://github.com/garabik/grc https://github.com/garabik/grc
radford-neal 5y ago
Great idea! For those wondering why anyone might not like their oh so beautiful colours... I like to set the background colour of the terminal to light green, and the text to black. It's much more relaxing. Coloured output is often illegible with this setup. Plus the colours are silly anyway...
- huachimingo 5y ago
  Like MSX's BASIC prompt.
  - Narishma 5y ago
    Wasn't that white on blue? I think it was the TRS CoCo that was black on green.
colordrops 5y ago
I'm starting to be of the mind that environment variables in general are an anti-pattern. They have arbitrary scope, their lifetime is not clear, and they are not easily composable. This was not something that bothered me so acutely until I started using declarative config with NixOS to configure my system, and found environment variables to be a big wart on this.
- dheera 5y ago
  Also, why NO_COLOR? That's "anti". It should be COLOR and set it to true or false.
  - chmod775 5y ago
    Possibly because the established default is colored output, and the absence of a boolean environment variable is generally treated as "false". It might also be that COLOR is already used for other purposes by some software.
    - npteljes 5y ago
      Let's call it MONOCHROME then. I too think that "disableSomething=enabled" naming schemes are confusing.
  - goodpoint 5y ago
    COLOR=(light|dark|none) would be much better.
  - kevincox 5y ago
    This also misses options such as letting COLOR=1 force colours which would be nice when I want to redirect "human" output to a file without bothering to set up a TTY. But I guess that ship has sailed.
- Gigachad 5y ago
  It’s a real pain when two things use the same name. Spent ages trying to debug an issue and it ended up being the distro I was using was setting “VERSION” which is generic enough that something else happened to be using it as well..
jachee 5y ago
If something doesn’t have an option to disable color, I simply pipe its output through `cat`. This is also handy for `git` commands that insist on showing a pager for fewer than a full screen worth of lines of output.
transfire 5y ago
Would a good terminal program support ANSI color mapping? Then you can change the mapping as desired — kind of like style-sheets for the shell.
quickthrower2 5y ago
Also have NO_EMOJI, NO_UNASCIIS, NO_ANIMATION, NO_CLEARING_SCREEN, NO_ADS …
- kleene_op 5y ago
  A few more suggestions: NO_TEXT, NO_TERMINAL, NO_FUN, NO_*, NO_NO
  - njacobs5074 5y ago
    JUST_SAY_NO? :)
obeattie 5y ago
Without understanding the minutiae of this, couldn’t someone just write a program that we can pipe any output to, which strips colour commands from its input before writing it back out? Does such a program already exist? That wouldn’t require every program to add support for an environment variable.
- alex_smart 5y ago
  Great question! There is ansi2txt (packaged as colorized-logs on debian). https://github.com/kilobyte/colorized-logs https://github.com/kilobyte/colorized-logs I also found some answers on SO with people using a sed command for this. https://stackoverflow.com/questions/17998978/removing-colors-from-output https://stackoverflow.com/questions/17998978/removing-colors...
- tgv 5y ago
  Often, `cat` will do that. Many tools look at stdout to see if it's a terminal. When it isn't, they suppress color output.
- lexicality 5y ago
  By itself, less will prevent any control sequences (including colours) from actually being sent to the terminal, but most distros seem to have -R set on it by default these days. If you unset -R it'll do exactly that.
maskaler 5y ago
I usually handle this inside code. Colour output operators make loss difficult to read. An associated commit and message is a sign to developers that the software runs in environments without colour consoles. Finding a way to shoehorn an environment variable into a build pipeline feels like an antipattern.
sharperguy 5y ago
This article reminds me a bit too much of https://xkcd.com/927/ https://xkcd.com/927/ Unless every program individually decides to implement NO_COLOR, this just adds yet another way that a program MIGHT allow you to disable color. Even if 90% of them implement it, it could just lead to issues whenever you unexpectedly run into a program in the remaining 10%.
- account42 5y ago
  So we shouldn't try to standardize things because the world is not perfect and there will be some issues where something does follow the standard? No.
xg15 5y ago
I agree that an env variable would be "philosophically" the right thing to do ("no colors" is a user choice and programs should respect user choices). However, giving a standard enough momentum so that most developers will actually implement it is an incredibly hard thing to do. I honestly don't have much hope that this will reach enough projects to be practically usable. At least not without support/enforcement by distributions. I also think that modifying shells instead could be a more pragmatic and effective solution - simply because there are less people you'd need to convince. You could get the same outcome however by having the shell interpret the NO_COLOR variable and have it strip colors from each subprocess where it is set. Also, I believe, most programs automatically disable colors when they detect that STDOUT does not point to a terminal. So couldn't you have the same effect by simply appending "| cat" to your command?
svilen_dobrev 5y ago
in the last 20~ years, i see more and more programmers not being able to read (source) code if it is not colored somehow. Or to navigate without a mouse. it's like you are on a journey, and your vehicle breaks in middle, and you do not continue by feet.. because you don't know you can walk.
- lexicality 5y ago
  Do you usually abandon your vehicle as soon as it breaks? Normally if I'm driving somewhere it's because walking would be impractical. If my car breaks I'm going to try and fix it rather than giving up and trying to carry my stuff by hand. Syntax highlighting vastly improves comprehension speed and accuracy. Why would you practice not having it?
  - svilen_dobrev 5y ago
    because you don't always have it. i heavily use syntax highlighting, and styling and other color-coding (e.g. file types/sizes in file manager), but i do not rely on it.
anthk 5y ago
This is good except for slash-em (too many mons with same letters).
vbezhenar 5y ago
I started to avoid tools dumping excessive color output, especially with emoji. This is ridiculous and extremely untasteful. Good tool must produce zero output.
Daub 5y ago
The difference between Colour and non-Colour is more precisely expressed as the difference between chromacity and lightness. We must not forget that chromatic vision developed after lightness vision. The former developed as response to the availability of fruit. Effectively, fruit and chromatic vision co-evolved. At a more experiential level, chromatic vision is an elaboration. It is not required, but in the lives of our ancestors, its presence signified the availability of a rare and pleasurable (carbohydrate intensive) experience. In design, this principle carries through. Colour is a layer that lays on top of the lightness experience.
nunez 5y ago
Didn’t even know that NO_COLOR was a thing. Thanks!
Flenser 5y ago
I just use a bash alias for striping colors: alias stripcolors=' sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"'

466 points by ducaale 5y ago

Submitted a few times in recent year. https://news.ycombinator.com/item?id=21171274 https://news.ycombinator.com/item?id=21171274 is the only one I can see, after a very cursory search, that got any discussion going at all.

blindmute 5y ago

>I want to use weird terminal themes that don't visually work well with most programs >therefore every single program must modify itself to accommodate me Uhhh, nope?

labster 5y ago

Title is incorrect. It should be NO_COLOR in all caps, like the environment variable.

roryokane 5y ago
Maybe Hacker News automatically recapitalized the title. It would make sense if it tries to forbid clickbaity titles like "ExampleDB, a POWERFUL NEW DATABASE".

gregmac 5y ago

> Why not just set $TERM to dumb or xterm without color support? Or change all color definitions in the terminal to print the same color? > The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown. I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. I respect others like no color (and there's already a solution per that, above), but I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale? Normally I wouldn't care, -- individual preferences are like opinions and everyone is entitled to their own -- but this imposes work on every developer/application. There's certainly ways to implement this that minimize impact, but it's still a non-zero up-front and ongoing maintenance/testing cost.

eterevsky 5y ago
There can be situations where the output intended for an ANSI terminal is shown as a raw text, including the color control sequences. Being able to switch off color should help with these situations.
twic 5y ago
> I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. There's a few programs i use where the colours were clearly chosen to work on a dark theme terminal. I use a light theme terminal, and they're illegible. I suppose the real problem here is that the output is tagged with physical colour, rather than some kind of semantic label which could be mapped to a colour in terminal configuration. But it's probably too late to do anything about that.
- edflsafoiewq 5y ago
  IME most programs still use the 8 traditional ANSI colors, which are exactly that (labels mapped to actual colors through config).
  - ncenvr 5y ago
    The problem here is that the 8 (or 16) ANSI colors are labels for just that: colors. 0 for black, 1 for red, etc. What OP is suggesting is more "abstract" labels, probably like "error" or "warning". More akin to text editor themes, which assign colors to particular semantic groups.
    - edflsafoiewq 5y ago
      The labels are abstract. You can make them whatever color you want. Basically every terminal theme does this.
      - nick__m 5y ago

scandox 5y ago

How generally are people dealing with these coloured logs when ingesting them into a centralized logging system? Is there much overhead in stripping these sort of things out.

jagger27 5y ago
Most of the time they’re not printed out at all because of isatty in underlying libraries. Centralized logging doesn’t usually go through a TTY.
- noitpmeder 5y ago
  This is the correct answer (or at least it should be). Only print colors when going to a TTY, not when writing logs to a file.
sverhagen 5y ago
I think that in some cases you end up capturing the control codes that control these colors, so then you want to disable the colored output explicitly.
hedora 5y ago
I think state of the art is to add a json output mode, then berate people that complain that neither option is ergonomic if you actually need to read production logs.
cyral 5y ago
I reported this issue four years ago to Google Cloud (not sure if it was ever fixed, no updates to the report), as they don't stripe out ANSI color codes nor render them, so our logs in their log viewer were full of gibberish from any colored messages.

bin_bash 5y ago

While this is a good standard, I often find myself just doing `somecommand | cat` whenever I want to get rid of colors. Usually they're disabled when outputting to a non-tty device.

jagger27 5y ago

Definitely adding this to my todo list to add to the CLI tools I help maintain. A lot of modern tools add emojis to output as well, which I sometimes find unnecessary in a similar way to terminal colours. NO_COLOR and NO_EMOJI seem reasonable. Any other ideas?

rsync 5y ago

I think this is a fine idea but I wonder about this part: "... should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color ..." How common is this behavior ? That is, the presence of the env var regardless of its value trips the conditional ? That seems like asking for trouble / confusion ... especially since there is a very well understood practice of setting 0/1 false/true for settings like this. Is this commonly done and I have just never noticed it ?

quesera 5y ago
I think it's fairly common. NO_COLOR=1 NO_COLOR=true NO_COLOR=yes Rather than parsing all the permutations, the usual evaluation of env vars that are expected to hold a boolean type is just the equivalent of: #ifdef NO_COLOR
- Monory 5y ago
  Well, in ZSH [[ -v VAR ]] can actually differentiate between unset and null variables And NO_COLOR= would lead to an non-intuitive behavior
  - Aeolun 5y ago
    I think the implication is that it should have a value.
chrisseaton 5y ago
> That is, the presence of the env var regardless of its value trips the conditional ? Pretty normal, yeah. You can `unset FOO` a variable to set it to false.
scatters 5y ago
It makes the logic simple in C (where the empty string is truthy); you can just write `if (getenv("FOO"))`.

alrs 5y ago

For tools that don't honor NO_COLOR, I have a filter called nofun, which gets rid of color and animations. https://github.com/alrs/nofun https://github.com/alrs/nofun

dijonman2 5y ago
You can also use col -bx
- alrs 5y ago
  Neat. col -bx leaves more artifacts lying around, but it does get the job done.
spicybright 5y ago
I hope the author of the article sees this, because this is absolutely the best solution to what they want to do. I'm sure you can even do some clever bash-foo to run your term sessions through it, like how screen or tmux work.
- viraptor 5y ago
  It works on stdout when using a pipe output, but it won't work with interactive apps using rich terminal capabilities and ncurses.
  - geophertz 5y ago
    What would prevent it from working with ncurses programs?
jart 5y ago
You can also pipe it through sed 's/\x1b\[[;0-9]*m//g'
- Qub3d 5y ago
  As noted in the repo README: > One could do this with GNU sed, but developers working in proprietary operating systems don't have GNU sed.

styfle 5y ago

I usually need the opposite, FORCE_COLOR=1, when non-TTY is detected but I still want colors.

layer8 5y ago
Many(?) tools support --color=always.
jhasse 5y ago
https://bixense.com/clicolors https://bixense.com/clicolors

Taniwha 5y ago

Oh yes! I am so over programs that output yellow text into a terminal with a white background and somehow expect people to be able to read the result

lolinder 5y ago
Don't most terminal themes map colors such that they're all mostly legible? And if not, wouldn't it be trivial to change yellow to an orange or brown? As a rule, I don't see any reason why a terminal theme should have any color that is illegible on its background. That feels like a problem with the theme more than with the program running on it.
- dahfizz 5y ago
  The exception is "true color" output[1]. In supported terminals you can make text any rgb value, regardless of theme. [1] https://gist.github.com/XVilka/8346728 https://gist.github.com/XVilka/8346728
  - lolinder 5y ago
    Fair. But presumably if you're doing that you're also specifying a good background color.
    - kevincox 5y ago
      You should? Yes. You are? Likely not. Developers will pick coliurs that look good on their theme and not even think about overriding the background colour until they get a bug report.
heavyset_go 5y ago
My pet peeve is purple and dark blue on black or gray backgrounds.

throwaway984393 5y ago

I wrote a shell script some time back that stripped ansi color from piped output. Haven't needed it since, but can't be hard to make again. So probably we don't need this kind of quasi-standard. (what's up with all the non-IETF "standards" all over HN and GitHub? there is an open standards process for technology, people. is the problem that us old folks never taught the youngsters how to make them?)

tomrod 5y ago

> While some developers and users obviously prefer seeing these colors, many users don’t. This is bold. (Pun intended). Colors are immensely beneficial for opt-in. I haven't heard very many complaints about it -- why does the author assume many users don't?

layer8 5y ago
Many doesn’t mean most, just a non-insignificant minority.
- tomrod 5y ago
  Ah, it's a weasel word -- an assertion that takes 10X the amount of effort to disprove than to make. Got it.
- mynameisash 5y ago
  I think the context here is trying to imply most: "While some developers ..., many users don’t." It's that 'many' is comparative to 'some' here.
  - tomrod 5y ago
    You hit the nail on the head. Until this thread, I've never heard complaints from developers I've worked with regarding terminal colors. I agree with the few comments that mention a fixed coloring on white background being miserable is a common-enough edge case that I hadn't considered before now (I've met two developers out of thousands who use light mode instead of dark mode, so my prior expectations were low).
jiggawatts 5y ago
... but which colours? Windows terminals mercifully had simply white-on-black for decades, but thanks to the various Azure and .NET Core teams, Microsoft has been invaded by Linux and Mac users. Now everything has to be CoLoUr all the time. Random colours. Colours that make no sense. RED ERRORS that are actually just titles. GREEN OKAY that's actually just a table header. Etc... I had the misfortune of being forced to use some Node and NPM tooling recently, having come from Visual Studio and C# programming. It was strangely nostalgic, like... stepping back in time to the 1990s and almost childish user interfaces. The spinning |/-\ symbols (with colours!) just killed me. I hadn't seen those since DOS 6. There's something perversely conservative about Linux. There's all this talk of how it's the best development environment, but to me all this "colors in the terminal" stuff just seems like a throwback to the days when I had a 486...

systemvoltage 5y ago

Unrelated but is there a standard that keeps my ~/ home directory clean? I don't want billion apps to write ~/.foo_software_config to my home dir. It is a complete mess.

loeg 5y ago
Nowadays well-behaved apps tend to use a single file or directory under ~/.config/. I believe it is a FreeDesktop.org standard: https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html https://specifications.freedesktop.org/basedir-spec/latest/a...
- ziml77 5y ago
  And on Windows that has just made the mess even worse. Applications writing to %USERPROFILE%\Documents, %APPDATA%, %LOCALAPPDATA%, %USERPROFILE%, and %USERPROFILE%\.config Every language needs something like this library as part of the standard library https://pypi.org/project/appdirs/ https://pypi.org/project/appdirs/ It would at least make it a little more likely that files end up where they should.
sneak 5y ago
XDG I believe is the name of the standard. https://wiki.debian.org/XDGBaseDirectorySpecification https://wiki.debian.org/XDGBaseDirectorySpecification
cturtle 5y ago
Yep, the XDG Base Directory specification [0]. Specifically the $XDG_CONFIG_HOME variable. [0]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
- samesamebutsame 5y ago
  The few things I have written always have the configs in here, seems like the polite thing to do without cluttering up home for the end user, but I can't help laugh when I look my own system and apps are storing gigabytes of data in there. It's not really a config folder anymore, more a misused general store for files.

deleted 5y ago

[deleted]

cturtle 5y ago

One question this leaves me with is regarding other ANSI escapes. Would a user with NO_COLOR be okay with bold, invert, italic, underline, or other effects? I’m happy to add support for NO_COLOR to the tool I maintain, but I think this proposal should be more clear in this regard. I would assume that COLOR implies that only color escapes should be disabled, but the description also mentions “plain” output.

lokedhs 5y ago
This problem was solved using the TERM environment variable, and it will just work when people use terminfo (and libraries that use it, such as ncurses). The problem is when people use explicit escape codes in their code rather than using libraries that solved this problem all the way back in the 80's. Yes, I'm somewhat grumpy about this because far too many times I have found log files filled with escape codes, or colours that are absolutely unreadable when using a terminal with white background.

drewg123 5y ago

What drives me insane is the UEFI shell using dark blue text for some things. That's impossible to read with a black background. The last place I want to squint and guess at what something says is when I'm applying a firmware update via a uefi tool, or un-foobaring a bootloader..

brandonbloom 5y ago

Competing standard for CLICOLOR and CLICOLOR_FORCE variables that have some support: https://bixense.com/clicolors/ https://bixense.com/clicolors/

IshKebab 5y ago
Yeah this is the earlier and better standard (more powerful and more precedent). The NO_COLOR guy should have dropped it as soon as people told him about this but now we have a stupid competing standards situation. If you support NO_COLOR you're making things worse.

TedShiller 5y ago

Part of the reason I avoid npm

dathinab 5y ago

> many users don’t. I doubt the "many" parts. It sooo much more readable if your program outputs a lot of data. And any (proper) implementation automatically switches the escape codes of if piping to another program instead of terminal so it rarely causes problems. I'm sure there are still some people which do not like it, and there are some libraries which mess up colors without doubt. So I'm fully in support of NO_COLOR as a "de-facto" standard.

tentacleuno 5y ago

This is the type of thing that should be supported in higher-level libraries like Chalk[0] (maybe it is?). We all know that Joe Bloggs' CLI isn't going to be checking for NO_COLOR. [0]: https://www.npmjs.com/package/chalk https://www.npmjs.com/package/chalk

aendruk 5y ago
The linked page lists thirty of them. Chalk isn’t on the list, but it used to be: https://github.com/jcs/no_color/commit/98857d0 https://github.com/jcs/no_color/commit/98857d0

somecommit 5y ago

spicybright 5y ago
I get what you mean, but you're not adding much to the discussion. I think of a few reasons you'd want to disable color that aren't for pure aesthetics: - Visually impaired users might have trouble with a lot of colors - Fully blind users won't see the color, so if it ties into a core feature of the tool, a NO_COLOR flag would force the developer to address it. For the record, I think the article OP linked to is pretty stupid in general, but I like playing devils advocate.
gkbrk 5y ago
If someone else becoming happy when their tools suit them better bothers you so much, maybe you should consider seeing one yourself.

ziml77 5y ago

I think it's reasonable to want an easy way to disable colored output, but I don't get why TERM doesn't work. Unless the request here is not for no colors but instead for fewer colors. But if it's to disable all colors in applications, then I believe changing TERM should work. And if you run something that you want colored you can override TERM for that process.

tadfisher 5y ago
TERM is a rather blunt instrument which changes support for many features besides ANSI color. SSH sessions further complicate matters. TERM=dumb is useful for cases where you absolutely want serialized output, such as CI logging. Interactive cases require you to choose a value that both your terminal emulator and the software supports.
- ziml77 5y ago
  I didn't know about TERM=dumb at all until last weekend when I was messing with Haskell. Without it, the line editor in the REPL was broken when moving through the history (in both Terminal.app and iTerm2). I was surprised that it worked though since I expected that TERM=dumb would result in the REPL not being able to use any ANSI escape codes.

atommclain 5y ago

Conversely if you want to add color to a command, I have found Generic Colorizer to be useful: https://github.com/garabik/grc https://github.com/garabik/grc

radford-neal 5y ago

Great idea! For those wondering why anyone might not like their oh so beautiful colours... I like to set the background colour of the terminal to light green, and the text to black. It's much more relaxing. Coloured output is often illegible with this setup. Plus the colours are silly anyway...

huachimingo 5y ago
Like MSX's BASIC prompt.
- Narishma 5y ago
  Wasn't that white on blue? I think it was the TRS CoCo that was black on green.

colordrops 5y ago

I'm starting to be of the mind that environment variables in general are an anti-pattern. They have arbitrary scope, their lifetime is not clear, and they are not easily composable. This was not something that bothered me so acutely until I started using declarative config with NixOS to configure my system, and found environment variables to be a big wart on this.

dheera 5y ago
Also, why NO_COLOR? That's "anti". It should be COLOR and set it to true or false.
- chmod775 5y ago
  Possibly because the established default is colored output, and the absence of a boolean environment variable is generally treated as "false". It might also be that COLOR is already used for other purposes by some software.
  - npteljes 5y ago
    Let's call it MONOCHROME then. I too think that "disableSomething=enabled" naming schemes are confusing.
- goodpoint 5y ago
  COLOR=(light|dark|none) would be much better.
- kevincox 5y ago
  This also misses options such as letting COLOR=1 force colours which would be nice when I want to redirect "human" output to a file without bothering to set up a TTY. But I guess that ship has sailed.
Gigachad 5y ago
It’s a real pain when two things use the same name. Spent ages trying to debug an issue and it ended up being the distro I was using was setting “VERSION” which is generic enough that something else happened to be using it as well..

jachee 5y ago

If something doesn’t have an option to disable color, I simply pipe its output through `cat`. This is also handy for `git` commands that insist on showing a pager for fewer than a full screen worth of lines of output.

transfire 5y ago

Would a good terminal program support ANSI color mapping? Then you can change the mapping as desired — kind of like style-sheets for the shell.

quickthrower2 5y ago

Also have NO_EMOJI, NO_UNASCIIS, NO_ANIMATION, NO_CLEARING_SCREEN, NO_ADS …

kleene_op 5y ago
A few more suggestions: NO_TEXT, NO_TERMINAL, NO_FUN, NO_*, NO_NO
- njacobs5074 5y ago
  JUST_SAY_NO? :)

obeattie 5y ago

Without understanding the minutiae of this, couldn’t someone just write a program that we can pipe any output to, which strips colour commands from its input before writing it back out? Does such a program already exist? That wouldn’t require every program to add support for an environment variable.

alex_smart 5y ago
Great question! There is ansi2txt (packaged as colorized-logs on debian). https://github.com/kilobyte/colorized-logs https://github.com/kilobyte/colorized-logs I also found some answers on SO with people using a sed command for this. https://stackoverflow.com/questions/17998978/removing-colors-from-output https://stackoverflow.com/questions/17998978/removing-colors...
tgv 5y ago
Often, `cat` will do that. Many tools look at stdout to see if it's a terminal. When it isn't, they suppress color output.
lexicality 5y ago
By itself, less will prevent any control sequences (including colours) from actually being sent to the terminal, but most distros seem to have -R set on it by default these days. If you unset -R it'll do exactly that.

maskaler 5y ago

I usually handle this inside code. Colour output operators make loss difficult to read. An associated commit and message is a sign to developers that the software runs in environments without colour consoles. Finding a way to shoehorn an environment variable into a build pipeline feels like an antipattern.

sharperguy 5y ago

This article reminds me a bit too much of https://xkcd.com/927/ https://xkcd.com/927/ Unless every program individually decides to implement NO_COLOR, this just adds yet another way that a program MIGHT allow you to disable color. Even if 90% of them implement it, it could just lead to issues whenever you unexpectedly run into a program in the remaining 10%.

account42 5y ago
So we shouldn't try to standardize things because the world is not perfect and there will be some issues where something does follow the standard? No.

xg15 5y ago

I agree that an env variable would be "philosophically" the right thing to do ("no colors" is a user choice and programs should respect user choices). However, giving a standard enough momentum so that most developers will actually implement it is an incredibly hard thing to do. I honestly don't have much hope that this will reach enough projects to be practically usable. At least not without support/enforcement by distributions. I also think that modifying shells instead could be a more pragmatic and effective solution - simply because there are less people you'd need to convince. You could get the same outcome however by having the shell interpret the NO_COLOR variable and have it strip colors from each subprocess where it is set. Also, I believe, most programs automatically disable colors when they detect that STDOUT does not point to a terminal. So couldn't you have the same effect by simply appending "| cat" to your command?

svilen_dobrev 5y ago

in the last 20~ years, i see more and more programmers not being able to read (source) code if it is not colored somehow. Or to navigate without a mouse. it's like you are on a journey, and your vehicle breaks in middle, and you do not continue by feet.. because you don't know you can walk.

lexicality 5y ago
Do you usually abandon your vehicle as soon as it breaks? Normally if I'm driving somewhere it's because walking would be impractical. If my car breaks I'm going to try and fix it rather than giving up and trying to carry my stuff by hand. Syntax highlighting vastly improves comprehension speed and accuracy. Why would you practice not having it?
- svilen_dobrev 5y ago
  because you don't always have it. i heavily use syntax highlighting, and styling and other color-coding (e.g. file types/sizes in file manager), but i do not rely on it.

anthk 5y ago

This is good except for slash-em (too many mons with same letters).

vbezhenar 5y ago

I started to avoid tools dumping excessive color output, especially with emoji. This is ridiculous and extremely untasteful. Good tool must produce zero output.

Daub 5y ago

The difference between Colour and non-Colour is more precisely expressed as the difference between chromacity and lightness. We must not forget that chromatic vision developed after lightness vision. The former developed as response to the availability of fruit. Effectively, fruit and chromatic vision co-evolved. At a more experiential level, chromatic vision is an elaboration. It is not required, but in the lives of our ancestors, its presence signified the availability of a rare and pleasurable (carbohydrate intensive) experience. In design, this principle carries through. Colour is a layer that lays on top of the lightness experience.

nunez 5y ago

Didn’t even know that NO_COLOR was a thing. Thanks!

Flenser 5y ago

I just use a bash alias for striping colors: alias stripcolors=' sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"'