9 ms·

> 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 cap

> 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
        The abstraction level is not high enough. As labels goes, color1 doesn't have the same semantic strength than error_color.
        edflsafoiewq 5y ago
        The less you know about them, the higher the abstraction. A program can distribute meaning over colorN in any way it wants. Any fixed semantic mapping would prove insufficient in the universe of all possible programs.
      - ncenvr 5y ago
        Perhaps in theory. Almost every application under the sun I've encountered expects 1 to be red, or 4 to be blue, or 3 to be yellow, or whatever. As an example, take solarized, or really any of the base16 themes. When I've used solarized in the past, many terminal programs that expect to print something in red are actually printing in a slightly-dimmed-background color, or purple, or something else where the intention of the tool author and the intention of the theme author conflict.
- wildzzz 5y ago
  Don't most terminal emulators allow you to set your own color palette? So what would show up as yellow text on a normal black background, you could change to show up as maybe as gold? Obviously it would mess with the meaning behind why the developer chose that particular color (like red errors, yellow or orange warnings) but I'm sure you'd get used to it.
  - hamburglar 5y ago
    Even though my terminal lets me do that, I’d rather just disable colors on some programs that choose poorly than spend time configuring that. I like your basic red=failure stuff so I don’t want to disable color entirely but I’m not going to spend time tweaking just because some joker decided dark blue on black looks neat.
  - laumars 5y ago
    There’s a few different sets of ansi escape sequences for managing colour. The ones you’re on about are the 8/16 colour palette. Unfortunately there is a trend these days for developers to use 8-bit (256 colours) pallet or even the true colour (24-bit). Both of the latter are not customisable in the terminal. Coincidentally I’ve gone into rants a number of times in the past on here about developers not using the correct colour palettes and the answer I always receive back for why it’s ok is because “developers should be able to chose how their application looks like”, which is fine if they control the entire design stack like they would on a website. But it makes zero sense in the terminal.
    - brundolf 5y ago
      Interesting, I didn't realize both kinds of control characters existed [checks the color library I'm currently using to build a CLI]
    - tetha 5y ago
      That makes sense. I've been wondering if we've been doing something subtly awkward with our internal tooling. However, most are just using the 8 or 16 color palette with a simple convention like "Use red (or technically, color 1, which just happens to be red for us) as error, yellow as warning, green as success" and let the terminal theme and the user figure out how it should look on their screen.
- Falkon1313 5y ago
  The physical colors are what the terminal configuration maps to. At least, modern terminals that I've used since the DOS era. Even back then, I had a tiny utility that I used to set the EGA palette for different text-mode programs. Amberscale tones on a deep low-saturation blue was one of my favorites. Obviously won't help if you're using a teletype or punched cards or something like that.
- CodeIsTheEnd 5y ago
  Guilty [1]. But it's really hard to handle both light and dark color themes! On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. Some color schemes intentionally invert the "bright" colors and makes them darker for a light colored scheme. This is what Gruvbox [2] does, but most other palettes don't. I also have an issue with Solarized which makes some of the Bright colors almost exactly the same as the foreground or background, which can make text printed in certain colors seem invisible. I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything. [1]: https://github.com/PaulJuliusMartinez/jless/issues/4 https://github.com/PaulJuliusMartinez/jless/issues/4 [2]: https://github.com/morhetz/gruvbox https://github.com/morhetz/gruvbox
  - dheera 5y ago
    Especially when no environment variable tells you whether to use light or dark.
    - bmn__ 5y ago
      The terminal itself can be queried. https://www.talisman.org/~erlkonig/documents/xterm-color-queries/ https://www.talisman.org/~erlkonig/documents/xterm-color-que...
  - manwe150 5y ago
    The design intent for Solarized is to minimize contrast, so this may lie somewhere between “you’re holding it wrong” territory, and aggressive cargo-culting advertising making this theme show up everywhere as an implied default good option. It is a nice set of color choices, but is not really appropriate for many situations where it gets used.
  - account42 5y ago
    > On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. The bright theme should invert the "dark" and "light" colors.
mediocregopher 5y ago
Most software that I use regularly which does color output does it well, and it's probably a net benefit for me. But sometimes software that I use irregularly, or only in specific circumstances, does it poorly, and it's a real pita. I've had occasions where I missed entire pieces of output because they rendered as the background color for some reason. So for those cases it'd be nice to have a universal switch, so to speak, to just turn it off. I also get that for some people it's just an aesthetic choice... I don't think color is _that_ helpful that someone would be impaired by not having it. All that said, this proposal reminds me of that one xkcd with the 13 competing standards.
manicdee 5y ago
Every application that supports colour already needs to support no colour for dumb terminals and pipes.
jim-jim-jim 5y ago
I still prefer color for matching quotes in editors. And they're useful in tui programs like cmus and tmux. And git add -p. That's about it for me though. I don't find it helpful in the output of package managers, ffmpeg, etc. It's clown vomit that makes things even harder to read imo. This env var wasn't a universal enough solution the last time I tried it, so I just set almost all my term colors except red (for the quote matching) to black. On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes.
- scythe 5y ago
  I like the colors from some commands (like ls) but I think everyone has had some experience with a command that has very bad colors, making some important information hard to read or just being really ugly. So the variable also provides a universal way to run any individual command without color if desired. >The default still seems to be very "gamer": dark mode, neon everything Dark mode is common but I've seen dull tones predominate for normal text over the last decade at least.
- opan 5y ago
  >On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes. Oh, come on... Look at the original terminals from the old days. Dark background with green or amber text. Dark terminals are the normal thing, nothing to do with gamers. My guess is it was less power to only light up the text parts instead of the inverse. Light themes, on a computer, seem unnatural in the way they force as much light as possible on. They're trying to emulate paper, which is white by default, but I don't think that should be considered normal on a computer.
  - jim-jim-jim 5y ago
    1. I think you're right about power. Even with PCs the folk wisdom during the CRT era was that having a black background would save energy. 2. Those early terminals were monochromatic though. They were stark and utilitarian, not the Vegas-ass colors some of my coworkers are rocking. 3. Paper is what I aim for. I have read black text all my life, including the textbooks that taught me to program, so it makes a lot of sense to work like this as well. I don't go full white though; Plan 9's Acme theme is the acme of palettes to me.
bitwize 5y ago
You've never had a program ANSI puke into a sink that expressly is not a terminal and expects only plain text -- for example, an Emacs buffer. Tired of setting magic flags on Maven to suppress color output when I do M-x compile, for instance.
- brundolf 5y ago
  Seems like it would be easy to make a program that strips color controls from stdin and pipes everything else to stdout
  - black_knight 5y ago
    I think Plan9port’s nobs command does this. It is my default pager when using acme or 9term (also from P9P).
  - eminence32 5y ago
    This is generally the behavior I've seen on my everyday apps that support color in their output. Often they have a `--color auto|never|always` command line option, with "auto" being the default, which detects if the output is a TTY or some other interactive terminal
    - brundolf 5y ago
      Auto-detecting is good, but I was suggesting a third-party program that just takes arbitrary input, strips the control characters, and produces the resulting output, in case the original app can't do what you need as a user
      - eminence32 5y ago
        Ah, yes. Sorry, I misread your comment. Yes, that is a good idea :)
      - MereInterest 5y ago
        This stack overflow post has a sed command that will strip them for you, so no need for a dedicated program. https://stackoverflow.com/a/18000433 https://stackoverflow.com/a/18000433
lom 5y ago
One case I can think of is parsing output without the intermittent hidden unicode codes to change the color. Changing terminal settings won’t change that.
- amscanne 5y ago
  Programs should disable terminal color codes when the output is not a terminal. Arguably, this is already an established best practice.
  - gary_0 5y ago
    If checking isatty() wasn't an established practice, pipes would be pretty useless.
- deleted 5y ago
  [deleted]
throw0101a 5y ago
> 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? The output is sometimes 'too busy' and the colours are of arbitrary values which may mean any number of things, and if you don't what they mean they're just noise. Further the same thing may be signified by different colours by different programs (editor A may have, e.g., variables as colour X, but editor B may have variables as colour Y, and the pager as colour Z). Perhaps if I was a coder, using one environment/editor/IDE, I could learn things. But as a sysadmin (whose been doing this for a few decades: Linux, BSD, Solaris, IRIX), I have never found colour† useful since I'm doing things in all sorts of contexts in the course of a day, and have never really found a need. † Besides the prompt perhaps.
- taneq 5y ago
  I imagine if you're hopping on and of dozens of different systems daily, it might help to have the host and username pop out at you even if everything else is greyscale. It's sort of how I always set VMs to have a dark grey flat background. Makes it easier to see at a glance whether you're in a fullscreen VM or the host system.
emeraldd 5y ago
Personally, I use NO_COLOR or other techniques to disable color when I'm logging output or using a CI/CD pipeline. Color codes tend to create all kinds of garbage in your logs otherwise.
- layer8 5y ago
  Software shouldn‘t output color when the output is redirected, unless something like `--color=always` is specified.
  - lilyball 5y ago
    CI often runs software in a pseudo-terminal.
    - deathanatos 5y ago
      Huh, I seem to have the opposite problem in that our CI doesn't emulate a terminal. (It should… but alas.) We're even moving to Github Actions, and that also doesn't.
- usr1106 5y ago
  I like color in my CI logs because it makes it easier for a human to spot various information. Obviously sometimes you might want to grep your logs and then color sequences might be annoying. I guess there is a command line tool / sed / awk oneliner to remove them. Unix filters are from the 1970s after all. The question is just what is the tool. I'd guess SO knows... But it's Sunday morning and I am on my phone not motivated to work :)
aidos 5y ago
There’s one I’ve come across recently here where you’re fighting against syntax highlighting with extra error context. https://github.com/ipython/ipython/issues/13446#issuecomment-1021630875 https://github.com/ipython/ipython/issues/13446#issuecomment...
NikolaNovak 5y ago
I like colour, but can easily empathise and visualize that I may like colour in applications I've configured, but found it obtrusive in something that vomits inconsistent, garish, distracting coloured output. So while I would not necessarily use this environment wetting, I can understand why some would treasure predictability and consistency. Note btw that one might have a wildly different perspective as e.G. Developer using a few tools on their own controlled desktop a lot, vs e.G. a sysadmin constantly jumping between large number of tools on large number of systems. As such, having a simple variable to shut up all the apps on all the servers may be quite handy.
lhorie 5y ago
> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. The main use case for this is that there are tools that use ANSI color libraries and don't handle non-colorization in non-TTY contexts. So what ends up happening is a user of said tool pipes its output to a log file and since ANSI escape codes are in-band, the log file becomes an unreadable mess. NO_COLOR provides a way for the library to give control over colorization to the user, even if the tool consuming the library hard codes colorization logic.
- afranchuk 5y ago
  I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.
  - noitpmeder 5y ago
    It's pretty bad for usability for all downstream tooling. Grepping log files is immediately worse... Ingestion into pipelines (like ELK) is considerably degraded... I can imagine almost every other tool would be similarly degraded. I think it's fine if the logs are going straight to stdout/stderr in a console. Any other destination (piped output, logfile) should default to no color.
    - mcswell 5y ago
      Grepping anything that has ANSI color codes would, I would think, be awful. Same for lots of other tools: sed, awk etc. So agreed, piped output should default to no color, and not just for the log file situation.
  - lilyball 5y ago
    A lot of display tools support them (though you might find issues with CI systems that show the lot in a web page) but a lot of processing tools don’t. For example, you might have difficulty using grep on your log file if there are escape codes sprinkled through it.
mushyhammer 5y ago
The answer is super easy: I want JSON to be shown with syntax highlight but when I pipe it elsewhere I want porcelain output. $NO_COLOR is an additional indicator that the output might need further processing and it’s not for human consumption (in a terminal) What you might be missing is that “color” on the CLI is actually extra characters before and after a colored word. If the viewer does not interpret them (for example a web UI), they will just be extra characters. This is akin to printing `<strong>8000 bytes</strong>` and expect it to be rendered correctly everywhere it’s shown.
adastra22 5y ago
Example: shell uses color for the prompt, but nothing else does. That way you can quickly scroll up and see your command prompt entries.
ok123456 5y ago
If you start using color, you need to consider accessibility. What if you use some combinations of foreground and background inadvertently that renders it unreadable. Also, there's no guarantee color pallets will be the same. There also needs to be a NO_EMOJI flag. I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts.
- deathanatos 5y ago
  > I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts. It doesn't take a Electron based terminal. iTerm2 on OS X supports emoji, and Terminal.app mostly does. Terminator on Linux supports them. (& which is based on VTE, so I sort of presume all VTE-based terminals do.) None of which are Electron based. (& I can understand not wanting that.) (Not to imply that a NO_EMOJI might have other merits.)
- opan 5y ago
  The noto emoji font is usually all you need, just having it installed is often enough for them to show if your terminal emulator supports fallback fonts (I think st doesn't, but most do). I support the idea of a NO_EMOJI env var anyway. I think theming should be left up to the user in nearly all cases and we shouldn't have colors or emoji forced on us. Devs could have something like alt text to show when emoji aren't there for cases where they're showing a meaning that the text doesn't.
taneq 5y ago
> I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale? The more sparingly you use colour, the more effective it is as a means to highlight important information. Different users think different information is important. I'm not sure how widespread it is but I work in the mining industry and I've seen a trend on newer installations towards keeping the general appearance of the entire interface to a couple of modestly contrasting neutral greys. Only parts of the plant which require operator attention are shown in colour (I think plant that's not in the normal automatic operation mode was yellow and alarms were red). The information's still all there and easy to read if the operator wants to, but it's not screaming for your attention unless it actually needs it. Compare this with the usual visual confetti of brightly flashing colours that a SCADA system devolves into, especially after a few years when a lot of 'important new features' have been added 'which the operator needs to see'.
pabs3 5y ago
It depends on the app, personally I prefer non-colorised UI of mc to the colorised UI. Elsewhere I used the colorised version.
bryanrasmussen 5y ago
my vision is degrading, and I have never seen a colored output where every color worked on the background color, it's really irritating with dark red error messages on black backgrounds for example because error messages are the kind of thing you really want to read and then I either need to zoom in a lot or in some cases copy the text of the message and put it into a text editor where I can read it.
janaagaard 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. Colorized output really sucks when the output is displayed in a terminal that doesn’t support it. Visual Studio’s build output, online build terminals like CircleCI, log viewers, … (Unsure if the ones I list above actually do have an issue with colors, but absolutely sure that I have seen it many times.)
mrighele 5y ago
A lot of these tools assume that you’re using a dark theme. If you’re using a white-ish background (even worse somewhat beige, like I do), things like text highlighted in yellow become invisible. Also, some of these tools don’t detect when they are run in a non interactive shell and will continue to write color codes when piped. A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection
- messe 5y ago
  > A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.
  - mrighele 5y ago
    For me no, but I think it depends a lot on the experience of the developer and the language it is using. And environment variable is more common knowledge, it's cross platform and supported in any decent language. I bet that many don't even know that something like isatty(3) exists.
    - zinekeller 5y ago
      > I bet that many don't even know that something like isatty(3) exists. Also shell scripts can't directly use that.
      - messe 5y ago
        Sure, and that's why POSIX provides `test -t`.
- goodpoint 5y ago
  Something like COLOR=(light|dark|none) would be much better.
abofh 5y ago
CI pipelines - I need clean readable output constantly, and having random escape codes all over the output just garbages up the flow into messages nobody reads. Setting NO_COLOR=1 once in the pipeline fixes 80% of output issues. Would it be nice if every pipeline tool supported the gambit of colors? Maybe, maybe I wouldn't care then. But as it is, more often than not, your cute colors just garbage up my build output.
citrin_ru 5y ago
1. I want to see color output in some commands, but not all of them (in some cases like with grep/ag it is very useful, in some cases colors are not useful or even makes it harder to read command output). NO_COLOR allows me to control output per-command by creating aliases 'env NO_COLOR=1 command' 2. Some color-using CLI tools assume white-ish background and actively use dark blue which is hard to see on a black background.
richardfey 5y ago
You must have never have dealt with Jenkins or some tool trying to parse standard error/output: it is hell with colorised outputs.
pid-1 5y ago
Some environments (e.g: AWS CloudWatch, many CI tools) won't parse colors and you end up with polluted text.
oq_pmg 5y ago
Why focus on imposing additional work on developers, rather than users (which, by the definition, is much wider audience) having to workaround hard-coded behavior? Adding color support to cli tools is an additional work for developers in the first place
erwincoumans 5y ago
>> so bad I wanted to disable them ls -la Some terminals have picked their default ls colors so bad that some entries are almost unreadable. Dark blue on black etc. Forced me to configure the LS_COLORS.
ayushnix 5y ago
> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. PuTTY comes to mind immediately upon reading this sentence. It is used more often than I like. https://www.chiark.greenend.org.uk/~sgtatham/putty/ https://www.chiark.greenend.org.uk/~sgtatham/putty/ The default colorscheme is extremely bad and if you use Vim to open log files, the comments are unreadable because they're colored as dark blue on a black background. Most of the other colors are unreadable as well. The widespread usage of PuTTY in my organization is the reason I have never written scripts or programs with colors, even though colors would help a lot of people differentiate between benign, warning, and error messages.

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
      The abstraction level is not high enough. As labels goes, color1 doesn't have the same semantic strength than error_color.
      - edflsafoiewq 5y ago
        The less you know about them, the higher the abstraction. A program can distribute meaning over colorN in any way it wants. Any fixed semantic mapping would prove insufficient in the universe of all possible programs.
    - ncenvr 5y ago
      Perhaps in theory. Almost every application under the sun I've encountered expects 1 to be red, or 4 to be blue, or 3 to be yellow, or whatever. As an example, take solarized, or really any of the base16 themes. When I've used solarized in the past, many terminal programs that expect to print something in red are actually printing in a slightly-dimmed-background color, or purple, or something else where the intention of the tool author and the intention of the theme author conflict.
wildzzz 5y ago
Don't most terminal emulators allow you to set your own color palette? So what would show up as yellow text on a normal black background, you could change to show up as maybe as gold? Obviously it would mess with the meaning behind why the developer chose that particular color (like red errors, yellow or orange warnings) but I'm sure you'd get used to it.
- hamburglar 5y ago
  Even though my terminal lets me do that, I’d rather just disable colors on some programs that choose poorly than spend time configuring that. I like your basic red=failure stuff so I don’t want to disable color entirely but I’m not going to spend time tweaking just because some joker decided dark blue on black looks neat.
- laumars 5y ago
  There’s a few different sets of ansi escape sequences for managing colour. The ones you’re on about are the 8/16 colour palette. Unfortunately there is a trend these days for developers to use 8-bit (256 colours) pallet or even the true colour (24-bit). Both of the latter are not customisable in the terminal. Coincidentally I’ve gone into rants a number of times in the past on here about developers not using the correct colour palettes and the answer I always receive back for why it’s ok is because “developers should be able to chose how their application looks like”, which is fine if they control the entire design stack like they would on a website. But it makes zero sense in the terminal.
  - brundolf 5y ago
    Interesting, I didn't realize both kinds of control characters existed [checks the color library I'm currently using to build a CLI]
  - tetha 5y ago
    That makes sense. I've been wondering if we've been doing something subtly awkward with our internal tooling. However, most are just using the 8 or 16 color palette with a simple convention like "Use red (or technically, color 1, which just happens to be red for us) as error, yellow as warning, green as success" and let the terminal theme and the user figure out how it should look on their screen.
Falkon1313 5y ago
The physical colors are what the terminal configuration maps to. At least, modern terminals that I've used since the DOS era. Even back then, I had a tiny utility that I used to set the EGA palette for different text-mode programs. Amberscale tones on a deep low-saturation blue was one of my favorites. Obviously won't help if you're using a teletype or punched cards or something like that.
CodeIsTheEnd 5y ago
Guilty [1]. But it's really hard to handle both light and dark color themes! On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. Some color schemes intentionally invert the "bright" colors and makes them darker for a light colored scheme. This is what Gruvbox [2] does, but most other palettes don't. I also have an issue with Solarized which makes some of the Bright colors almost exactly the same as the foreground or background, which can make text printed in certain colors seem invisible. I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything. [1]: https://github.com/PaulJuliusMartinez/jless/issues/4 https://github.com/PaulJuliusMartinez/jless/issues/4 [2]: https://github.com/morhetz/gruvbox https://github.com/morhetz/gruvbox
- dheera 5y ago
  Especially when no environment variable tells you whether to use light or dark.
  - bmn__ 5y ago
    The terminal itself can be queried. https://www.talisman.org/~erlkonig/documents/xterm-color-queries/ https://www.talisman.org/~erlkonig/documents/xterm-color-que...
- manwe150 5y ago
  The design intent for Solarized is to minimize contrast, so this may lie somewhere between “you’re holding it wrong” territory, and aggressive cargo-culting advertising making this theme show up everywhere as an implied default good option. It is a nice set of color choices, but is not really appropriate for many situations where it gets used.
- account42 5y ago
  > On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. The bright theme should invert the "dark" and "light" colors.

mediocregopher 5y ago

Most software that I use regularly which does color output does it well, and it's probably a net benefit for me. But sometimes software that I use irregularly, or only in specific circumstances, does it poorly, and it's a real pita. I've had occasions where I missed entire pieces of output because they rendered as the background color for some reason. So for those cases it'd be nice to have a universal switch, so to speak, to just turn it off. I also get that for some people it's just an aesthetic choice... I don't think color is _that_ helpful that someone would be impaired by not having it. All that said, this proposal reminds me of that one xkcd with the 13 competing standards.

manicdee 5y ago

Every application that supports colour already needs to support no colour for dumb terminals and pipes.

jim-jim-jim 5y ago

I still prefer color for matching quotes in editors. And they're useful in tui programs like cmus and tmux. And git add -p. That's about it for me though. I don't find it helpful in the output of package managers, ffmpeg, etc. It's clown vomit that makes things even harder to read imo. This env var wasn't a universal enough solution the last time I tried it, so I just set almost all my term colors except red (for the quote matching) to black. On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes.

scythe 5y ago
I like the colors from some commands (like ls) but I think everyone has had some experience with a command that has very bad colors, making some important information hard to read or just being really ugly. So the variable also provides a universal way to run any individual command without color if desired. >The default still seems to be very "gamer": dark mode, neon everything Dark mode is common but I've seen dull tones predominate for normal text over the last decade at least.
opan 5y ago
>On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes. Oh, come on... Look at the original terminals from the old days. Dark background with green or amber text. Dark terminals are the normal thing, nothing to do with gamers. My guess is it was less power to only light up the text parts instead of the inverse. Light themes, on a computer, seem unnatural in the way they force as much light as possible on. They're trying to emulate paper, which is white by default, but I don't think that should be considered normal on a computer.
- jim-jim-jim 5y ago
  1. I think you're right about power. Even with PCs the folk wisdom during the CRT era was that having a black background would save energy. 2. Those early terminals were monochromatic though. They were stark and utilitarian, not the Vegas-ass colors some of my coworkers are rocking. 3. Paper is what I aim for. I have read black text all my life, including the textbooks that taught me to program, so it makes a lot of sense to work like this as well. I don't go full white though; Plan 9's Acme theme is the acme of palettes to me.

bitwize 5y ago

You've never had a program ANSI puke into a sink that expressly is not a terminal and expects only plain text -- for example, an Emacs buffer. Tired of setting magic flags on Maven to suppress color output when I do M-x compile, for instance.

brundolf 5y ago
Seems like it would be easy to make a program that strips color controls from stdin and pipes everything else to stdout
- black_knight 5y ago
  I think Plan9port’s nobs command does this. It is my default pager when using acme or 9term (also from P9P).
- eminence32 5y ago
  This is generally the behavior I've seen on my everyday apps that support color in their output. Often they have a `--color auto|never|always` command line option, with "auto" being the default, which detects if the output is a TTY or some other interactive terminal
  - brundolf 5y ago
    Auto-detecting is good, but I was suggesting a third-party program that just takes arbitrary input, strips the control characters, and produces the resulting output, in case the original app can't do what you need as a user
    - eminence32 5y ago
      Ah, yes. Sorry, I misread your comment. Yes, that is a good idea :)
    - MereInterest 5y ago
      This stack overflow post has a sed command that will strip them for you, so no need for a dedicated program. https://stackoverflow.com/a/18000433 https://stackoverflow.com/a/18000433

lom 5y ago

One case I can think of is parsing output without the intermittent hidden unicode codes to change the color. Changing terminal settings won’t change that.

amscanne 5y ago
Programs should disable terminal color codes when the output is not a terminal. Arguably, this is already an established best practice.
- gary_0 5y ago
  If checking isatty() wasn't an established practice, pipes would be pretty useless.
deleted 5y ago
[deleted]

throw0101a 5y ago

> 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? The output is sometimes 'too busy' and the colours are of arbitrary values which may mean any number of things, and if you don't what they mean they're just noise. Further the same thing may be signified by different colours by different programs (editor A may have, e.g., variables as colour X, but editor B may have variables as colour Y, and the pager as colour Z). Perhaps if I was a coder, using one environment/editor/IDE, I could learn things. But as a sysadmin (whose been doing this for a few decades: Linux, BSD, Solaris, IRIX), I have never found colour† useful since I'm doing things in all sorts of contexts in the course of a day, and have never really found a need. † Besides the prompt perhaps.

taneq 5y ago
I imagine if you're hopping on and of dozens of different systems daily, it might help to have the host and username pop out at you even if everything else is greyscale. It's sort of how I always set VMs to have a dark grey flat background. Makes it easier to see at a glance whether you're in a fullscreen VM or the host system.

emeraldd 5y ago

Personally, I use NO_COLOR or other techniques to disable color when I'm logging output or using a CI/CD pipeline. Color codes tend to create all kinds of garbage in your logs otherwise.

layer8 5y ago
Software shouldn‘t output color when the output is redirected, unless something like `--color=always` is specified.
- lilyball 5y ago
  CI often runs software in a pseudo-terminal.
  - deathanatos 5y ago
    Huh, I seem to have the opposite problem in that our CI doesn't emulate a terminal. (It should… but alas.) We're even moving to Github Actions, and that also doesn't.
usr1106 5y ago
I like color in my CI logs because it makes it easier for a human to spot various information. Obviously sometimes you might want to grep your logs and then color sequences might be annoying. I guess there is a command line tool / sed / awk oneliner to remove them. Unix filters are from the 1970s after all. The question is just what is the tool. I'd guess SO knows... But it's Sunday morning and I am on my phone not motivated to work :)

aidos 5y ago

There’s one I’ve come across recently here where you’re fighting against syntax highlighting with extra error context. https://github.com/ipython/ipython/issues/13446#issuecomment-1021630875 https://github.com/ipython/ipython/issues/13446#issuecomment...

NikolaNovak 5y ago

I like colour, but can easily empathise and visualize that I may like colour in applications I've configured, but found it obtrusive in something that vomits inconsistent, garish, distracting coloured output. So while I would not necessarily use this environment wetting, I can understand why some would treasure predictability and consistency. Note btw that one might have a wildly different perspective as e.G. Developer using a few tools on their own controlled desktop a lot, vs e.G. a sysadmin constantly jumping between large number of tools on large number of systems. As such, having a simple variable to shut up all the apps on all the servers may be quite handy.

lhorie 5y ago

> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. The main use case for this is that there are tools that use ANSI color libraries and don't handle non-colorization in non-TTY contexts. So what ends up happening is a user of said tool pipes its output to a log file and since ANSI escape codes are in-band, the log file becomes an unreadable mess. NO_COLOR provides a way for the library to give control over colorization to the user, even if the tool consuming the library hard codes colorization logic.

afranchuk 5y ago
I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.
- noitpmeder 5y ago
  It's pretty bad for usability for all downstream tooling. Grepping log files is immediately worse... Ingestion into pipelines (like ELK) is considerably degraded... I can imagine almost every other tool would be similarly degraded. I think it's fine if the logs are going straight to stdout/stderr in a console. Any other destination (piped output, logfile) should default to no color.
  - mcswell 5y ago
    Grepping anything that has ANSI color codes would, I would think, be awful. Same for lots of other tools: sed, awk etc. So agreed, piped output should default to no color, and not just for the log file situation.
- lilyball 5y ago
  A lot of display tools support them (though you might find issues with CI systems that show the lot in a web page) but a lot of processing tools don’t. For example, you might have difficulty using grep on your log file if there are escape codes sprinkled through it.

mushyhammer 5y ago

The answer is super easy: I want JSON to be shown with syntax highlight but when I pipe it elsewhere I want porcelain output. $NO_COLOR is an additional indicator that the output might need further processing and it’s not for human consumption (in a terminal) What you might be missing is that “color” on the CLI is actually extra characters before and after a colored word. If the viewer does not interpret them (for example a web UI), they will just be extra characters. This is akin to printing `<strong>8000 bytes</strong>` and expect it to be rendered correctly everywhere it’s shown.

adastra22 5y ago

Example: shell uses color for the prompt, but nothing else does. That way you can quickly scroll up and see your command prompt entries.

ok123456 5y ago

If you start using color, you need to consider accessibility. What if you use some combinations of foreground and background inadvertently that renders it unreadable. Also, there's no guarantee color pallets will be the same. There also needs to be a NO_EMOJI flag. I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts.

deathanatos 5y ago
> I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts. It doesn't take a Electron based terminal. iTerm2 on OS X supports emoji, and Terminal.app mostly does. Terminator on Linux supports them. (& which is based on VTE, so I sort of presume all VTE-based terminals do.) None of which are Electron based. (& I can understand not wanting that.) (Not to imply that a NO_EMOJI might have other merits.)
opan 5y ago
The noto emoji font is usually all you need, just having it installed is often enough for them to show if your terminal emulator supports fallback fonts (I think st doesn't, but most do). I support the idea of a NO_EMOJI env var anyway. I think theming should be left up to the user in nearly all cases and we shouldn't have colors or emoji forced on us. Devs could have something like alt text to show when emoji aren't there for cases where they're showing a meaning that the text doesn't.

taneq 5y ago

> I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale? The more sparingly you use colour, the more effective it is as a means to highlight important information. Different users think different information is important. I'm not sure how widespread it is but I work in the mining industry and I've seen a trend on newer installations towards keeping the general appearance of the entire interface to a couple of modestly contrasting neutral greys. Only parts of the plant which require operator attention are shown in colour (I think plant that's not in the normal automatic operation mode was yellow and alarms were red). The information's still all there and easy to read if the operator wants to, but it's not screaming for your attention unless it actually needs it. Compare this with the usual visual confetti of brightly flashing colours that a SCADA system devolves into, especially after a few years when a lot of 'important new features' have been added 'which the operator needs to see'.

pabs3 5y ago

It depends on the app, personally I prefer non-colorised UI of mc to the colorised UI. Elsewhere I used the colorised version.

bryanrasmussen 5y ago

my vision is degrading, and I have never seen a colored output where every color worked on the background color, it's really irritating with dark red error messages on black backgrounds for example because error messages are the kind of thing you really want to read and then I either need to zoom in a lot or in some cases copy the text of the message and put it into a text editor where I can read it.

janaagaard 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. Colorized output really sucks when the output is displayed in a terminal that doesn’t support it. Visual Studio’s build output, online build terminals like CircleCI, log viewers, … (Unsure if the ones I list above actually do have an issue with colors, but absolutely sure that I have seen it many times.)

mrighele 5y ago

A lot of these tools assume that you’re using a dark theme. If you’re using a white-ish background (even worse somewhat beige, like I do), things like text highlighted in yellow become invisible. Also, some of these tools don’t detect when they are run in a non interactive shell and will continue to write color codes when piped. A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection

messe 5y ago
> A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.
- mrighele 5y ago
  For me no, but I think it depends a lot on the experience of the developer and the language it is using. And environment variable is more common knowledge, it's cross platform and supported in any decent language. I bet that many don't even know that something like isatty(3) exists.
  - zinekeller 5y ago
    > I bet that many don't even know that something like isatty(3) exists. Also shell scripts can't directly use that.
    - messe 5y ago
      Sure, and that's why POSIX provides `test -t`.
goodpoint 5y ago
Something like COLOR=(light|dark|none) would be much better.

abofh 5y ago

CI pipelines - I need clean readable output constantly, and having random escape codes all over the output just garbages up the flow into messages nobody reads. Setting NO_COLOR=1 once in the pipeline fixes 80% of output issues. Would it be nice if every pipeline tool supported the gambit of colors? Maybe, maybe I wouldn't care then. But as it is, more often than not, your cute colors just garbage up my build output.

citrin_ru 5y ago

1. I want to see color output in some commands, but not all of them (in some cases like with grep/ag it is very useful, in some cases colors are not useful or even makes it harder to read command output). NO_COLOR allows me to control output per-command by creating aliases 'env NO_COLOR=1 command' 2. Some color-using CLI tools assume white-ish background and actively use dark blue which is hard to see on a black background.

richardfey 5y ago

You must have never have dealt with Jenkins or some tool trying to parse standard error/output: it is hell with colorised outputs.

pid-1 5y ago

Some environments (e.g: AWS CloudWatch, many CI tools) won't parse colors and you end up with polluted text.

oq_pmg 5y ago

Why focus on imposing additional work on developers, rather than users (which, by the definition, is much wider audience) having to workaround hard-coded behavior? Adding color support to cli tools is an additional work for developers in the first place

erwincoumans 5y ago

>> so bad I wanted to disable them ls -la Some terminals have picked their default ls colors so bad that some entries are almost unreadable. Dark blue on black etc. Forced me to configure the LS_COLORS.

ayushnix 5y ago

> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. PuTTY comes to mind immediately upon reading this sentence. It is used more often than I like. https://www.chiark.greenend.org.uk/~sgtatham/putty/ https://www.chiark.greenend.org.uk/~sgtatham/putty/ The default colorscheme is extremely bad and if you use Vim to open log files, the comments are unreadable because they're colored as dark blue on a black background. Most of the other colors are unreadable as well. The widespread usage of PuTTY in my organization is the reason I have never written scripts or programs with colors, even though colors would help a lot of people differentiate between benign, warning, and error messages.