1. 33

  2. 6

    A shame, because people who want a bit of colour or a lot of colour can’t express their preference with this env-var.

    Why not COLOR={none/some/lots/unicorn-vomit}?

    1. 16

      I suspect anything more complicated than an opt-out would involve endless subjective bike shedding and have even less uniform an implementation.

      Also, it should be NO_COLOUR obviously!

      1. 2

        Nice try, but the language of the internet is American and not English ;-)

        1. 2

          The language of the world wide web is misspelled American English, to be precise. Just look at the HTTP headers your browser sends to see to what it is that I am a Referer. ;)

      2. 1

        That would’ve been cool, but I suspect it would’ve been far less likely to take off. With the current NO_COLOR design, libraries for handling color can automatically just return the original text instead of the text with color control codes if NO_COLOR exists unless explicitly overridden. Applications which don’t use libraries generally already check if stdout is a tty; they could just change isatty(STDOUT_FILENO) to isatty(STDOUT_FILENO) && !getenv("NO_COLOR") (assuming they already have ways to override that check).

        Your best bet is probably to enable NO_COLOR and then, for the pieces of software you want color output from, configure them explicitly.

      3. 3

        A missed opportunity to support 3 colors selection: none / light-on-dark / dark-on-light

        1. 3

          In general, negative variables (NO_FOO, disable_bar) are not a good idea for extensibility.

          Other missed opportunity: because the site wants programs to check if NO_COLOR is set to any value, there’s no scope to do something like NO_COLOR=prog1,prog2,progN.

          General principle: don’t slap the first idea on a webpage and say “let’s make a standard”.

        2. 1

          Usecase: User does not want to see colors on their terminal -> Disable colors in Terminal configuration

          Usecase: Program is not writing to a terminal -> Programs should check if stdout is a tty and check for existence of $TERM variable

          Is there something i miss? I don’t get the necessity for this.

          1. 6

            The article goes into this. Users might well want to explicity configure some tools (e.g. an editor) to output color, but don’t want to spammed with useless color output by a package manager.

            (I’m particularly irritated by command line tools whose color output was clearly not tested outside leet darkmode terminals.)

            1. 4

              (I’m particularly irritated by command line tools whose color output was clearly not tested outside leet darkmode terminals.)

              Thank goodness! Someone else who thinks the same thing.

              1. 3

                I think the term you want is “angry fruit salad”, and I quite concur. The people who choose default colours in terminal programs I use occasionally (but not often enough to bother with configuring) all seem to have a fetish for garish shrieking colours.

              2. 3

                I use eshell, and ansi-color codes aren’t always supported, but it’s not quite a dumb term either. I stumbled upon this link while trying to find a way to disable unnecessary color-codes being generated by apt (I know there are other ways, but I wanted to know if this was possible). If this were a pervasive standard, I would have a better experience with tools like these, by default.

                1. 1

                  My predicament is similar: my main working terminal emulator is M-x shell, and some of the newer cli tools completely disregard the fact that it is pretty much a dumb terminal.

              3. 0

                It makes this variable usable only when set to true, which is not how environment variables should be used.

                1. 2

                  Could you elaborate more about why environment variables shouldn’t be used to hold boolean data?

                  1. 1

                    All command-line software which outputs text with ANSI color added should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color.

                    So it’s not “true”, it’s any value. As far as I understand empty string would do too.

                    One can easily remove variable from environment, and check for existence is simple and unambiguous.

                    How environment variables should be used for boolean data instead of this? Or you mean that environment variables are not designed for boolean data?

                  Stories with similar links:

                  1. NO_COLOR: disabling ANSI color output in various Unix commands via technetium 3 months ago | 24 points | 18 comments