No_color(no-color.org)
no-color.org
No_color
https://no-color.org/
213 comments
> Also the arguments regarding colorblind crowd being unable to distinguish colors are weak
Especially since accessibility in terminal environments simply isn't a thing. The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators, they cannot know which texts belong together, what their semantic relation is, etc. etc.
If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Proper accessibility requires semantic labeling of visual output, and the terminal display protocol doesn't provide that capability. Hand-wringing about a specific aspect like color blindness only serves to avoid discussing the elephant in the room, which is that TUI programs are fundamentally not accessible.
Especially since accessibility in terminal environments simply isn't a thing. The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators, they cannot know which texts belong together, what their semantic relation is, etc. etc.
If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Proper accessibility requires semantic labeling of visual output, and the terminal display protocol doesn't provide that capability. Hand-wringing about a specific aspect like color blindness only serves to avoid discussing the elephant in the room, which is that TUI programs are fundamentally not accessible.
I've heard from multiple blind people over the years that terminals are actually quite nice to work with, exactly because it's "just text" without too much bruhaha.
> The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators [...].
In the default state (not on the “alternate screen” and with wrapping enabled; i.e. in ls not vim) terminal emulators do record which runs of text belong together and which don’t, in order to be able to rewrap lines if the user resizes the window. (This is as universal as it is unspecified. Which is a shame, because it’s highly non-obvious how this should interact with e.g. programmatic cursor movement.) I know nothing about the accessibility story, but the “grid of cells” picture is simply untrue.
In the default state (not on the “alternate screen” and with wrapping enabled; i.e. in ls not vim) terminal emulators do record which runs of text belong together and which don’t, in order to be able to rewrap lines if the user resizes the window. (This is as universal as it is unspecified. Which is a shame, because it’s highly non-obvious how this should interact with e.g. programmatic cursor movement.) I know nothing about the accessibility story, but the “grid of cells” picture is simply untrue.
This is false. Only GUI terminal emulators do it this way, and only some of them. Programs like BRLTTY can attach to the likes of screen(1) sessions and kernel virtual terminals. KVTs very much do have grids of cells, and that's exactly what BRLTTY opens and reads, as a matter of fact. A vcsa device file is an array of character+attribute pairs.
Garbage take. The terminal is quite good to work with when you are dependent on a screen reader, because its is already a serial text stream that can be converted into speech quite easily. This is a contrast to regular GUI which needs to be serialized first.
And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported.
And yes, you cannot use all TUI programs (like vi for example), but you can reliably disable these programs by using a terminfo with the hardcopy flag set.
And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported.
And yes, you cannot use all TUI programs (like vi for example), but you can reliably disable these programs by using a terminfo with the hardcopy flag set.
> And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported.
Why is this on me and not the developer of the screenreader application?
Why is this on me and not the developer of the screenreader application?
I was someone trying to connect a linux pty with the espeak backend.
[deleted]
BRLTTY, for one, reads vcsa devices, which don't see CSI colour sequences at all, but are straightforward arrays of character+attribute pairs.
There is more accessability besides screen readers. Not all people are blind. Some people just want bigger fonts and better contrast.
This is a point of frustration for me -- I have reduced vision, but I wouldn't even qualify as legally blind. It impacts me to the degree that I don't drive a car, which is pretty inconvenient living in America.
There's a whole world of options between "tiny fonts on a high resolution screen" and "screen reader" but things like large fonts, legibility-focused typefaces, zoomable applications and high contrast don't seem to be a priority (looking at you, MacOS).
This is all a big part of why I work primarily in a terminal emulator. I can control all of these things.
There's a whole world of options between "tiny fonts on a high resolution screen" and "screen reader" but things like large fonts, legibility-focused typefaces, zoomable applications and high contrast don't seem to be a priority (looking at you, MacOS).
This is all a big part of why I work primarily in a terminal emulator. I can control all of these things.
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable.
They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. Sometimes people without any disability prefer e.g. high-contrast modes, some people just dislike rapidly flashing lights even if they don't get seizures from it, some may just see no benefit in terminal coloring except in some rare cases.
Many terminal programs already support various color output options, additionally checking an environment variable isn't a big deal and doesn't affect anyone not using it.
They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. Sometimes people without any disability prefer e.g. high-contrast modes, some people just dislike rapidly flashing lights even if they don't get seizures from it, some may just see no benefit in terminal coloring except in some rare cases.
Many terminal programs already support various color output options, additionally checking an environment variable isn't a big deal and doesn't affect anyone not using it.
> They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind.
I'm always curious what someone means when they say that something "is not binary". The phrase seems to imply that the situation is more complicated than it appears at a glance, but I've noticed a pattern in which the people who claim things to be "non-binary" habitually dismiss valid prose before actually engaging with them. They don't tend to actually explain themselves, they simply spout unverified information as if it is truth.
I'm always curious what someone means when they say that something "is not binary". The phrase seems to imply that the situation is more complicated than it appears at a glance, but I've noticed a pattern in which the people who claim things to be "non-binary" habitually dismiss valid prose before actually engaging with them. They don't tend to actually explain themselves, they simply spout unverified information as if it is truth.
It's programmer's version of "it's not black or white".
In this case, a program isn't "accessible" or "not accessible" but rather degrees of accessibility. Not everyone is 100% blind, so small accessibility features makes it easier for them while not being accessible to 100% of the population.
In this case, a program isn't "accessible" or "not accessible" but rather degrees of accessibility. Not everyone is 100% blind, so small accessibility features makes it easier for them while not being accessible to 100% of the population.
> It's programmer's version of "it's not black or white".
I am aware. My issue is with people using the phrase as if the folks they are arguing with aren't aware that the world isn't black and white, but actually a complicated place in which nuance and forethought are the norm.
I am aware. My issue is with people using the phrase as if the folks they are arguing with aren't aware that the world isn't black and white, but actually a complicated place in which nuance and forethought are the norm.
To be fair, parent poster did write:
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable.
Which seems to indicate they see accessibility as something that is black or white, either you're accessible and don't write TUI programs, or you go ahead and write TUI programs and forget any sort of accessibility.
While the reality is that even if you write TUI programs, you can make them more accessible by following paradigms like "don't just use colors as visual indicators".
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable.
Which seems to indicate they see accessibility as something that is black or white, either you're accessible and don't write TUI programs, or you go ahead and write TUI programs and forget any sort of accessibility.
While the reality is that even if you write TUI programs, you can make them more accessible by following paradigms like "don't just use colors as visual indicators".
To be clear, my issue is with the phrasing "non-binary". Imo, such phrasing attempts to squelch discourse by attempting to claim authority. If you claim that something is "non-binary"... can you use your words to explain how? A "binary" situation means that one of two things will happen. How is your example excused from binary representation?
In this case, it seems a perfectly valid choice of words.
"irreconcilable" basically implies that there is a binary choice -- either use a TUI or aim for accessibility, but you can't have both. The responder was saying that actually it's not a binary choice -- there are degrees of accessibility, and some accessibility can be attained within a TUI.
Disagreeing with someone, using valid arguments, is not the same as squelching discourse.
"irreconcilable" basically implies that there is a binary choice -- either use a TUI or aim for accessibility, but you can't have both. The responder was saying that actually it's not a binary choice -- there are degrees of accessibility, and some accessibility can be attained within a TUI.
Disagreeing with someone, using valid arguments, is not the same as squelching discourse.
> Disagreeing with someone, using valid arguments, is not the same as squelching discourse.
I can relate with your position; I understand what you're saying. I guess my point is that some words that humans speak can strike a nerve in others. For instance, apparently I'm a huge Temple Grandin fan. I didn't know that until I mentioned the name Temple Grandin to my girlfriend of nearly five years recently and she basically snapped and told me that she never wanted me to say that name again. Apparently when I first met her I had a lot of good things to say about Temple Grandin, and I guess throughout the following five years I've mentioned Temple Grandin enough that it just raises her hackles when she hears it now. She's a good person, and absolutely does not have anything against Temple Grandin. She just doesn't like hearing that name when it's my voice speaking it.
I can relate with your position; I understand what you're saying. I guess my point is that some words that humans speak can strike a nerve in others. For instance, apparently I'm a huge Temple Grandin fan. I didn't know that until I mentioned the name Temple Grandin to my girlfriend of nearly five years recently and she basically snapped and told me that she never wanted me to say that name again. Apparently when I first met her I had a lot of good things to say about Temple Grandin, and I guess throughout the following five years I've mentioned Temple Grandin enough that it just raises her hackles when she hears it now. She's a good person, and absolutely does not have anything against Temple Grandin. She just doesn't like hearing that name when it's my voice speaking it.
hehe yes I can relate to that!
I'm not sure if you had this in mind when you said "non-binary", but I also think along the same lines you just noted, that there is a difference between "not binary", and "non-binary". The latter could evoke connotations to the culture wars and gender identity -- though that of course has nothing to do with accessibility (of TUIs, bathrooms might be another matter).
Then again, I'm neither American nor a native English speaker, so I hardly have much authority on this point.
I'm not sure if you had this in mind when you said "non-binary", but I also think along the same lines you just noted, that there is a difference between "not binary", and "non-binary". The latter could evoke connotations to the culture wars and gender identity -- though that of course has nothing to do with accessibility (of TUIs, bathrooms might be another matter).
Then again, I'm neither American nor a native English speaker, so I hardly have much authority on this point.
I'm sorry that people downvoted you (they did it to me too, so I can commiserate). Imo, your question is totally valid. It's likely that you are correct in this case, and that I am in fact subconsciously relating the aforementioned phrase that annoys me with the painful period of social upheaval that we experienced here in the US.
It's important to remember that during that time, many words were misappropriated (edit) by both sides in order to fit an agenda. Before that period of upheaval, the phrases that were misappropriated were not generally offensive, even to the people who found them confusing. Up until that point I truly believe that most people regarded such unrelatable concepts (i.e. a person identifying as something other than their physical makeup would suggest) as being simply unrelatable, but tolerable. I don't think most people had strong feelings one way or the other before the upheaval. I think when I hear those "dirty" words now though, that I experience some form of PTSD. The people with the megaphone (again, on all sides) did a damn fine job dividing all of us, imo.
It's important to remember that during that time, many words were misappropriated (edit) by both sides in order to fit an agenda. Before that period of upheaval, the phrases that were misappropriated were not generally offensive, even to the people who found them confusing. Up until that point I truly believe that most people regarded such unrelatable concepts (i.e. a person identifying as something other than their physical makeup would suggest) as being simply unrelatable, but tolerable. I don't think most people had strong feelings one way or the other before the upheaval. I think when I hear those "dirty" words now though, that I experience some form of PTSD. The people with the megaphone (again, on all sides) did a damn fine job dividing all of us, imo.
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable.
If I write for myself and package/publish for others, the user has a choice not to use my program.
If I write for myself and package/publish for others, the user has a choice not to use my program.
Emacs is fine at screen reading in a terminal environment.
Do you mean for simple command line output, or also for actual TUIs, like htop and vim? If the latter, how does that even work? Presumably you'd have to configure it on a per-TUI basis, which is exactly the point of the parent -- it's not accessible out of the box, no matter what you do...right? Or can it be more clever than that?
Emacs has Emacspeak which works on everything.
I'll give you an argument: it's difficult to read colored output, at least for me. Perhaps it is because I'm colorblind, idk, but the output of e.g. "ls" makes it hard to find certain files. The directory names get all fuzzy, and 'tgz' files scream. It takes much more effort to parse than uncolored output. And terminal colors are just garish, but that's a matter of taste.
> accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means
Yeah, we might not agree on that. That practice might be a tad overrated or overused. In some contexts it might make sense, but that doesn't mean any semantic difference should be expressed. E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? Why not color by file size? Or by age? How am I going to remember those colors? Plus, it's unusable in a script, because then "ls" suppresses the color.
But why argue (pretty harshly) against a proposal that won't affect the way you see the output? And why give such a weird, unfriendly option to remove color?
> accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means
Yeah, we might not agree on that. That practice might be a tad overrated or overused. In some contexts it might make sense, but that doesn't mean any semantic difference should be expressed. E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? Why not color by file size? Or by age? How am I going to remember those colors? Plus, it's unusable in a script, because then "ls" suppresses the color.
But why argue (pretty harshly) against a proposal that won't affect the way you see the output? And why give such a weird, unfriendly option to remove color?
> And terminal colors are just garish, but that's a matter of taste.
You can change the specific colors used by your terminal emulator, at least for the basic 16 colors.
> E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names?
I agree that coloring .tgz is useless. But it is useful to be able to tell directories, executables, symlinks apart (I also use the -F flag to have a textual indicator).
> Did I ask for it?
Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Why is the default wallpaper of Windows 11 a blue flower-ish thing? Did I ask for it?
Software has defaults, and then Linux distros may add their customizations on top. Are those defaults the universal best way to do things? No. But usually, you can just customize them to your liking.
You can change the specific colors used by your terminal emulator, at least for the basic 16 colors.
> E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names?
I agree that coloring .tgz is useless. But it is useful to be able to tell directories, executables, symlinks apart (I also use the -F flag to have a textual indicator).
> Did I ask for it?
Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Why is the default wallpaper of Windows 11 a blue flower-ish thing? Did I ask for it?
Software has defaults, and then Linux distros may add their customizations on top. Are those defaults the universal best way to do things? No. But usually, you can just customize them to your liking.
> You can change the specific colors used by your terminal emulator, at least for the basic 16 colors.
Doesn't that contradict the "semantic marking" argument? Now you can't predict what the output will look like, and someone might like the color of grep output, but not ls.
I simply alias most commands that output color, BTW. The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line. At least, I wouldn't know how. NO_COLOR=true/false could be switched per command.
> Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Apart from the fact that looking for a name becomes harder (and you clearly don't know what you're looking for if you only use ls), that ls -1tr is your friend, and that there always is some order, last-use order doesn't make sense for other cmd line utilities. There's no point in a global "SORT_ORDER=last-use" environment variable.
Doesn't that contradict the "semantic marking" argument? Now you can't predict what the output will look like, and someone might like the color of grep output, but not ls.
I simply alias most commands that output color, BTW. The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line. At least, I wouldn't know how. NO_COLOR=true/false could be switched per command.
> Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Apart from the fact that looking for a name becomes harder (and you clearly don't know what you're looking for if you only use ls), that ls -1tr is your friend, and that there always is some order, last-use order doesn't make sense for other cmd line utilities. There's no point in a global "SORT_ORDER=last-use" environment variable.
> The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line.
There is no need. An empty string is equivalent according to the spec, so:
> The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
I have more luck with setting the environment variables, e.g.
There is no need. An empty string is equivalent according to the spec, so:
NO_COLOR= command
> The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
I have more luck with setting the environment variables, e.g.
LS_COLORS="rs=0:di=0:ln=0:mh=0:pi=0:so=0:do=0:bd=0:cd=0:or=0:mi=0:su=0:sg=0:ca=0:tw=0:ow=0:st=0:ex=0:*=0:"
GREP_COLORS=ms=0:mc=0:sl=:cx=:fn=0:ln=0:bn=0:se=0> The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line. At least, I wouldn't know how.
env -u NO_COLOR command...
env -u NO_COLOR command...
You can change the specific color shades to something nicer, but keep the color mapping the same (1=red, 2=green etc.), just like most of these themes: https://github.com/lysyi3m/macos-terminal-themes
ls assigned colors because it was configured to do so, either by you or your distribution.
> plus, it's unusable in a script, because then "ls" suppresses the color.
ls doesn't do anything different in a script, you probably just have an ls alias. Aliased are typically not sourced for non interactive shells
> plus, it's unusable in a script, because then "ls" suppresses the color.
ls doesn't do anything different in a script, you probably just have an ls alias. Aliased are typically not sourced for non interactive shells
it depends on the invocation, and by default it checks for tty or not. the aliasing often does not touch this.
example alias:
("tty" and "if-tty" are the same as "auto")
example alias:
$ alias ls
ls='ls --color=tty'
("tty" and "if-tty" are the same as "auto")
alias ls='ls -F'> Also the arguments regarding colorblind crowd being unable to distinguish colors are weak, as accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means, so that everybody has their chance to understand it (e.g. setting links in a distinguished color and underlined).
It's not color blindness, it's lack of basic testing in real-world conditions where not everyone can use dark-themed terminals.
The default colors in Debian's 'ls' output, or 'ncdu', blend perfectly with a light background theme, so the net result is a loss of information for the user.
It's not color blindness, it's lack of basic testing in real-world conditions where not everyone can use dark-themed terminals.
The default colors in Debian's 'ls' output, or 'ncdu', blend perfectly with a light background theme, so the net result is a loss of information for the user.
I'm using terminals with dark background and often suffer from programs using dark blue which is hard to distinguish from the background (even with changes in terminal settings to make it less dark). So at least some by default expect light background. Vim being one of them (I have to keep COLORFGBG='default;default;0' in environment for it).
vim predates the fashion for dark backgrounds, so it gets it wrong for a different subset of people. Try `set background=dark` in your .vimrc.
(I believe neovim uses the DCS 11 inquiry to determine the actual background colour on xterm-compatibles. I believe vim currently does not, relying on environment variables only. I may be stale or otherwise mistaken on both.)
(I believe neovim uses the DCS 11 inquiry to determine the actual background colour on xterm-compatibles. I believe vim currently does not, relying on environment variables only. I may be stale or otherwise mistaken on both.)
> vim predates the fashion for dark backgrounds,
If anything, the correct version of this statement would be "Vim was created when light backgrounds were a fad".
The "natural" background of the terminal is dark, including ADM-3A (terminal "responsible" of vi's HJKL).
If anything, the correct version of this statement would be "Vim was created when light backgrounds were a fad".
The "natural" background of the terminal is dark, including ADM-3A (terminal "responsible" of vi's HJKL).
The “natural” background for text is light though. Hard to find books, newspapers, or magazines that put a dark background behind text of any significant length.
Accordingly, the Xerox Alto had a light background too, back in the 1970s. Demonstrated here with Smalltalk:
https://youtu.be/NqKyHEJe9_w
And here with a GUI based text editor:
https://youtu.be/2Z43y94Dfzk
Accordingly, the Xerox Alto had a light background too, back in the 1970s. Demonstrated here with Smalltalk:
https://youtu.be/NqKyHEJe9_w
And here with a GUI based text editor:
https://youtu.be/2Z43y94Dfzk
As did Engelbart's NLS, as seen in ‘the mother of all demos’. https://www.youtube.com/watch?v=yJDv-zdhzMY
What little actual research exists suggests dark on light is more readable for people with normal vision. People with cataracts benefit from light on dark, and people with astigmatism benefit from dark on light.
What little actual research exists suggests dark on light is more readable for people with normal vision. People with cataracts benefit from light on dark, and people with astigmatism benefit from dark on light.
Light background for books IMHO is no more natural than dark background for old CRT displays - both are what works best for a given medium: while making dark paper is not harder than light one, it is hard to make a pencil or ink which would be clearly visible on black paper (white markers do exists but they are a recent invention). Blackboard and chalk where natural until we got plastic whiteboards and easy to erase markers.
Modern screens are more or less unique in not limiting background colors so we can use any and and argue which one is better.
Modern screens are more or less unique in not limiting background colors so we can use any and and argue which one is better.
Actually there is at least one more common media where we can freely choose between dark and light (at least in the last 100+ years) - guide signs on roads. Both options are common (e. g. white on green/blue and black on white). But even if there are studies showing which background is better for signs it is not necessary the same for a computer screen: road sign should be legible from a maximum distance under variety of conditions - from a sunny day to LED lighting at nigh or heavy rain. Legibility is the main design goal. Computers on other hand are usually used in an environment where we can control lighting to some degree and a distance is fixed. Legibility is important but comfort is important as well (choose of colors should minimize eye strain / fatigue in case if it can affect this).
Use the Tango color scheme.
Very colorblind here. I would much rather have accessible use of color than black and white. The whole thing is like saying that the best way to accommodate wheelchairs is to bulldoze the world to completely level everywhere.
No. Accessibility is about awareness. We use ramps, rails, elevators, and other tools to make a 3D world accessible to people who rely on wheels.
Similarly, here is the one thing you need to know to use color accessibly: think in HSB (or HSL or HSV), and always vary at least two of those dimensions.
I am fine if you want to use red/green for status as long as it is light red and dark green (or vice versa).
Encoding information redundantly in two dimensions makes the result accessible to those who can’t see some/all difference in one of those dimensions.
There. Now you can enjoy your damn purple skies and green fire trucks without worrying about me.
No. Accessibility is about awareness. We use ramps, rails, elevators, and other tools to make a 3D world accessible to people who rely on wheels.
Similarly, here is the one thing you need to know to use color accessibly: think in HSB (or HSL or HSV), and always vary at least two of those dimensions.
I am fine if you want to use red/green for status as long as it is light red and dark green (or vice versa).
Encoding information redundantly in two dimensions makes the result accessible to those who can’t see some/all difference in one of those dimensions.
There. Now you can enjoy your damn purple skies and green fire trucks without worrying about me.
> as accessibility best practices suggest to convey semantically relevant markup
You may have missed that this is about CLI applications, not web-pages.
You may have missed that this is about CLI applications, not web-pages.
I stopped reading right after that silly comment - the world is full of colors!
> If your software outputs color by default, please consider not doing so.
Why? What specific benefit does that convey to my users? When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
There is exactly one use case for this, and that's programmatically processing output in a pipline. And that one is a solved problem, as good libraries for colored output usually check isatty()
And before anyone says "colorblindness": I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
Why? What specific benefit does that convey to my users? When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
There is exactly one use case for this, and that's programmatically processing output in a pipline. And that one is a solved problem, as good libraries for colored output usually check isatty()
And before anyone says "colorblindness": I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
> When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
This is the truth about every decision one makes, even if the reason is trivial, fleeting, or barely overruled some opposing reasoning, which shouldn't mean that no one can suggest anything to you. This is someone trying to affect your future decisionmaking, not to take the decision from you.
> I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
Maybe they're not on their home machine or terminal?
This is the truth about every decision one makes, even if the reason is trivial, fleeting, or barely overruled some opposing reasoning, which shouldn't mean that no one can suggest anything to you. This is someone trying to affect your future decisionmaking, not to take the decision from you.
> I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
Maybe they're not on their home machine or terminal?
I don't remember what was the last instance of a command barfing ansi escape sequences into a non-tty output stream, but it was just a couple days ago. I encounter badly-behaved software more frequently than your seem to, and I have more confidence in "don't provide colour (or other fancy text) unless the user asks for it" than "it's fine except for this set of exceptions that who knows if it's complete or not".
Sure, but that has a simple solution not even mentioned in this post: isatty(1)
Just remember that stdout and stderr can be both a tty, neither a tty or one is a tty while the other is not.
> Why? What specific benefit does that convey to my users?
Readability, reduced visual noise, and compatibility with any terminal color scheme.
> When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
Was your reason something other than preference? If not, did you consider that others may have different preferences?
Readability, reduced visual noise, and compatibility with any terminal color scheme.
> When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
Was your reason something other than preference? If not, did you consider that others may have different preferences?
> Readability, reduced visual noise,
Semantically colored text, by definition, reduces visual noise. After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
Semantically colored text, by definition, reduces visual noise. After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
Then, by definition, most use of color in the command line is not semantic, because it increases visual noise for me.
You may like color, that's fine. But for me, the effect of colored text as it is used today is akin to prose with every other word randomly colored[1], often in a color that blends in with the background of the page.
Turning off the colors, for me, is a large improvement. Using them sparingly, carefully, with a preference for bolding and italicizing to make metadata stand out from data, would be better. This is far harder to patch in to most programs, and a much larger uphill battle. Turning off colors is, by and large, the low hanging fruit.
[1] https://cdn.gbraad.nl/images/blog/english-text-highlighting....
You may like color, that's fine. But for me, the effect of colored text as it is used today is akin to prose with every other word randomly colored[1], often in a color that blends in with the background of the page.
Turning off the colors, for me, is a large improvement. Using them sparingly, carefully, with a preference for bolding and italicizing to make metadata stand out from data, would be better. This is far harder to patch in to most programs, and a much larger uphill battle. Turning off colors is, by and large, the low hanging fruit.
[1] https://cdn.gbraad.nl/images/blog/english-text-highlighting....
> Semantically colored text, by definition, reduces visual noise.
Not by definition. It adds information. If that matches the text 100%, it is redundant. If it isn't, it adds noise. So it depends very much of what you consider "noise".
> After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
I'm curious what you think are good sources for that. Many studies have been done on color and text, but I've never seen one that gives a good argument in favor of coloring command line output.
Note: recall isn't a goal of color in (most) command line output. Perhaps there is some case, but I wouldn't know which one.
Not by definition. It adds information. If that matches the text 100%, it is redundant. If it isn't, it adds noise. So it depends very much of what you consider "noise".
> After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
I'm curious what you think are good sources for that. Many studies have been done on color and text, but I've never seen one that gives a good argument in favor of coloring command line output.
Note: recall isn't a goal of color in (most) command line output. Perhaps there is some case, but I wouldn't know which one.
> If that matches the text 100%, it is redundant. If it isn't, it adds noise.
Information is only noise if it isn't the signal you are after. Also if the text contains some information that doesn't mean color can't make it easier to distinguish.
Information is only noise if it isn't the signal you are after. Also if the text contains some information that doesn't mean color can't make it easier to distinguish.
Instead of trying to get every CLI tool in existence follow this standard, it makes much more sense to put this support in the terminal emulator or shell. Both can know what process is in the foreground and can strip color or let color through based on a user-configured whitelist/blacklist.
I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks.
I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
That's already a solved problem though, with a different solution - programs should be checking `isatty()` and not output escape sequences if it's not going to a real tty. That's how `ls` can display colors by default but still not have them show up if you pipe `ls` into a command.
This page seems to purely be about interactive use with no color.
This page seems to purely be about interactive use with no color.
The isatty() check is obnoxious when you do want to preserve the control chars and can't force it on.
That's why you pair it with a command line switch:
--color=auto (default, isatty + termcap)
--color=always
--color=never
Now if we could only agree on a standard to do this using environment variables... Unfortunately, the most widely known "standard" [0], is still very rarely supported.
[0] https://bixense.com/clicolors/
Now if we could only agree on a standard to do this using environment variables... Unfortunately, the most widely known "standard" [0], is still very rarely supported.
[0] https://bixense.com/clicolors/
That's a pretty niche case, you can force it by either allocating a pseudo tty or using LD_PRELOAD with an isatty() shim that returns true.
I only ever had to do it once (using LD_PRELOAD) because there was an insane vendor binary blob that would return "SUCCESS" in green/red depending on if it passed or failed. When isatty() returned false, it was impossible to tell if it passed or failed, but the software was pure garbage.
I only ever had to do it once (using LD_PRELOAD) because there was an insane vendor binary blob that would return "SUCCESS" in green/red depending on if it passed or failed. When isatty() returned false, it was impossible to tell if it passed or failed, but the software was pure garbage.
> That's a pretty niche case
I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example.
Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today.
¹ https://news.ycombinator.com/item?id=36102160
² https://github.com/kilobyte/colorized-logs
I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example.
Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today.
¹ https://news.ycombinator.com/item?id=36102160
² https://github.com/kilobyte/colorized-logs
> I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks.
Most programs that output color already disable color if the output isn't a terminal; in fact I just pipe the output to cat when I want color off.
Most programs that output color already disable color if the output isn't a terminal; in fact I just pipe the output to cat when I want color off.
[deleted]
Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want?
The author has a use case (I believe their issue is that unlike $NO_COLOR, setting $TERM takes precedence over any configs or --color flags), though to me it seems like a rather niche problem. Anyways, if you support $TERM, it's easy to support $NO_COLOR as well, so there's not much of a reason to not follow the standard.
The author has a use case (I believe their issue is that unlike $NO_COLOR, setting $TERM takes precedence over any configs or --color flags), though to me it seems like a rather niche problem. Anyways, if you support $TERM, it's easy to support $NO_COLOR as well, so there's not much of a reason to not follow the standard.
> Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want?
Lots of software out there, especially from nodebros, blithely ignores $TERM and just barfs ANSI escape codes to standard out, under the rubric that, well, everybody uses macOS Terminal/iTerm/Alacritty.
Lots of software out there, especially from nodebros, blithely ignores $TERM and just barfs ANSI escape codes to standard out, under the rubric that, well, everybody uses macOS Terminal/iTerm/Alacritty.
True. But this is a problem that should be addressed with equal to if not far more fervour than pushing some other environment variable.
Because although the meanings aren't specified the TERM environment variable itself is named in the Single Unix Specification, unlike some other environment variables (even COLORTERM).
And the TERM=dumb convention is documented widely and long, at least as far back as 1983, in books and in on-line doco.
* It's in the McGraw-Hill book _Introducing the UNIX System_published in 1983. Amusingly, this uses the C shell setenv syntax to demonstrate setting it, indicating how the C shell was the Bourne Again shell of its time.
* It's in the 4BSD manual page for TERM(7) from 1985. It's still in the OpenBSD manual page for term(7) to this day: https://man.openbsd.org/term.7 . The 4BSD TERM(7) manual had a list of well-known types, and "dumb \ \ \ \ \ \ \ \ terminals with no special features" was one of them. See https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/man/... for example.
* It is the documented default fallback for AT&T Unix System 5 Release 4's tset(1) command when nothing in the the ttytype(5) file matches. "If the serial port is not found in /etc/ttytype, the terminal type is set to dumb." said the USL manual.
(No, it's not the ncurses tset(1)'s fallback. Bear in mind that the "n" in "ncurses" meant "new". ncurses was a reimplementation. Like many reimplementations, it missed bits of actual System 5 Release 4.)
* Setting TERM to the right thing instead of a dumb terminal type in order to enable colour is in Coffin's _UNIX System V Release 4 Complete Reference_ published in 1991.
This is how long and wide a pedigree TERM=dumb has.
Even I, who is progressive enough that I have joined the bright new future of 1976, with my softwares defaulting to TERM=ansi if it isn't set, document the convention that TERM=dumb meant using no escape or control sequences and just (a few) C0 control codes such as LF and CR. See https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .
Because although the meanings aren't specified the TERM environment variable itself is named in the Single Unix Specification, unlike some other environment variables (even COLORTERM).
And the TERM=dumb convention is documented widely and long, at least as far back as 1983, in books and in on-line doco.
* It's in the McGraw-Hill book _Introducing the UNIX System_published in 1983. Amusingly, this uses the C shell setenv syntax to demonstrate setting it, indicating how the C shell was the Bourne Again shell of its time.
* It's in the 4BSD manual page for TERM(7) from 1985. It's still in the OpenBSD manual page for term(7) to this day: https://man.openbsd.org/term.7 . The 4BSD TERM(7) manual had a list of well-known types, and "dumb \ \ \ \ \ \ \ \ terminals with no special features" was one of them. See https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/man/... for example.
* It is the documented default fallback for AT&T Unix System 5 Release 4's tset(1) command when nothing in the the ttytype(5) file matches. "If the serial port is not found in /etc/ttytype, the terminal type is set to dumb." said the USL manual.
(No, it's not the ncurses tset(1)'s fallback. Bear in mind that the "n" in "ncurses" meant "new". ncurses was a reimplementation. Like many reimplementations, it missed bits of actual System 5 Release 4.)
* Setting TERM to the right thing instead of a dumb terminal type in order to enable colour is in Coffin's _UNIX System V Release 4 Complete Reference_ published in 1991.
This is how long and wide a pedigree TERM=dumb has.
Even I, who is progressive enough that I have joined the bright new future of 1976, with my softwares defaulting to TERM=ansi if it isn't set, document the convention that TERM=dumb meant using no escape or control sequences and just (a few) C0 control codes such as LF and CR. See https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .
It may be old but it isn't popular. I've spent 10k+ hours in the terminal and don't remember ever seeing it mentioned.
Almost all software that outputs colors only checks if the output is a TTY and doesn't look at the TERM variable.
Almost all software that outputs colors only checks if the output is a TTY and doesn't look at the TERM variable.
Not true. Indeed, very much the other way around. All software that uses the terminfo or termcap databases looks at the TERM variable and gets the TERM=dumb effect from that for free. That's every shell script that uses tput to change colours, and every program that calls the low level tgetent()/tigetstr() (or the equivalents in unibilium or termdb) or that uses curses/ncurses.
This is a wide range of softwares from the %F and %B sequences in the Z shell's prompt through Midnight Commander to the clang++ compiler.
You've clearly either never looked at much doco or have a truly terrible memory. In addition to all of the books and whatnot over a span of 40 years, even The Linux Documentation Project got in on the act: https://tldp.org/HOWTO/Text-Terminal-HOWTO-8.html#early_term...
And StackOverflow: https://stackoverflow.com/a/39005551/340790
This is a wide range of softwares from the %F and %B sequences in the Z shell's prompt through Midnight Commander to the clang++ compiler.
You've clearly either never looked at much doco or have a truly terrible memory. In addition to all of the books and whatnot over a span of 40 years, even The Linux Documentation Project got in on the act: https://tldp.org/HOWTO/Text-Terminal-HOWTO-8.html#early_term...
And StackOverflow: https://stackoverflow.com/a/39005551/340790
Most of the software that outputs colors are scripts or CLI programs that use hard-coded ANSI escape sequences, not termcap or those library functions.
You haven't measured it, and the large number of questions and answers on just Unix StackExchange, without checking all of the others from AskUbuntu to SuperUser that are like https://unix.stackexchange.com/a/327544/5132 indicates that yes, people do use tput in scripts as a matter of course.
I don't know all the intricate details of how these things work, but my general impression is that the terminal should really not be able to see or modify data being sent over pipes. The shell can, but you wouldn't want it unconditionally scraping and "cleaning" what is usually an opaque binary stream (even if it contains mostly text). So you can make it an option, but wouldn't it be better if programs just provided a standard way to turn off color coding?
I personally don’t like having to ask a friend to adjust a bunch of terminal settings (or worse, use a specifically accessible terminal like you are suggesting) just so I can look over their shoulder without my eyes bleeding.
I also don’t think anyone is asking you to go change all the software in the world to support NO_COLOR=1 just to help people out.
I do think it would be great if the next time you thought about putting a little colour in your application that you consider supporting $NO_COLOR to disable it. It would help me and others out if I ever found myself using your software.
I do agree that the terminal you suggest (if it existed and were common) _would_ be better than NO_COLOR=1 but I hope you can also understand we don’t live in that world, and that the “best” solution in one way, isn’t always the best way to help people out.
Finally, I hope very much that you can think about accessibility in the future: asking the disabled to work harder is not a kindness- it may be unrealistic to do anything else, but you can try to make it as easy as you can, and that is a kindness.
I also don’t think anyone is asking you to go change all the software in the world to support NO_COLOR=1 just to help people out.
I do think it would be great if the next time you thought about putting a little colour in your application that you consider supporting $NO_COLOR to disable it. It would help me and others out if I ever found myself using your software.
I do agree that the terminal you suggest (if it existed and were common) _would_ be better than NO_COLOR=1 but I hope you can also understand we don’t live in that world, and that the “best” solution in one way, isn’t always the best way to help people out.
Finally, I hope very much that you can think about accessibility in the future: asking the disabled to work harder is not a kindness- it may be unrealistic to do anything else, but you can try to make it as easy as you can, and that is a kindness.
Colors are usually stripped when the output is piped, so simply piping a command through cat should already do this most of the time.
Using a global standard for color configuration would be nice, though. I often want coloured output and am left with all kinds of command line flags or environment variables just to get tools to output text normally.
Using a global standard for color configuration would be nice, though. I often want coloured output and am left with all kinds of command line flags or environment variables just to get tools to output text normally.
That’s still up to the developer of the producer to implement
Piping to cat won't work for an interactive tool though.
Agree, but even for terminal emulators imo it's better to put that as an option in the config menu / file instead of an ENV variable
terminal emulators dont actually know this. Just think of executing something via ssh. In this case the primary foreground process is ssh.
Yeah. If you don't like colors just diable them from the terminal.
They address this FAQ on the linked page:
> 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.
> It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author.
> 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.
> It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author.
Is there some reason why we can’t just implement this once in each terminal?
Go into the settings, set “no colour” and it just strips all the escape codes from the stream?
Or just outright ignore them?
I guess it feels weird to want to make this the problem of every CLI application developer.
Go into the settings, set “no colour” and it just strips all the escape codes from the stream?
Or just outright ignore them?
I guess it feels weird to want to make this the problem of every CLI application developer.
I want colour, in certain places, under my control. I don't want every random tool spewing confetti.
So you want every developer to spend time on both color and non-color options but are not willing to contribute a patch for that?
I have no problem contributing patches, but nothing I currently use regularly is ill-behaved.
Not using colour is no work at all. Using colour correctly is a fair bit of work, and few programs do so; practically none check whether the terminal background is dark or light before emitting a dark blue or light yellow.
Not using colour is no work at all. Using colour correctly is a fair bit of work, and few programs do so; practically none check whether the terminal background is dark or light before emitting a dark blue or light yellow.
Aside from your uncharitable interpretation: it is really not difficult or time-consuming to support this. It's just setting and checking a single boolean flag, in fact it may simply just be a few lines at startup if the tool already supports color options via cli args.
Indeed, if one uses the termcap or terminfo libraries (or the likes of unibilium) to obtain the control sequences for colour from those databases, instead of hardwiring them into the source code of print statements, one gets the TERM=dumb convention implemented entirely for free.
In this case it seems pretty easy to contribute a patch? Mature projects have unit and screendiff test suites that need to be updated and extended to verify the new case, so it might not be THAT easy even for a trivial change.
> Mature projects have unit and screendiff test suites
Good joke.
Good joke.
You could copy an existing terminfo entry and remove the colour.
Or use an existing one like ansi-mono
Or use an existing one like ansi-mono
[deleted]
I read the page before commenting and it didn't address my point. That answer is about why it's not satisfactory to simply disable all color in the terminal. I'm talking about adding a color whitelist/blacklist feature to a terminal emulator.
You don't know which process it is. The color producing program can be embedded in a script or running in an ssh session.
No, it really doesn't. There are so many tools that already respect this variable that if you're writing a new tool, and you're not looking for that variable, you are being a bad actor and need to be told to shape up.
For any new programs I make that involve terminal, I'm going to make them respect NO_COLOR as it seems pretty trivial.
> "If your software outputs color by default, please consider not doing so."
I'd love to hear good reasoning why using color by default is bad. I can think of some arguments for doing so but the website is not elaborating. E.g. default color choices assume dark terminal or they are not modifiable or developers in general tend to do a bad job at it or something along those lines etc.
I think color can make reading faster and easier, it's why syntax highlighting exists.
> "If your software outputs color by default, please consider not doing so."
I'd love to hear good reasoning why using color by default is bad. I can think of some arguments for doing so but the website is not elaborating. E.g. default color choices assume dark terminal or they are not modifiable or developers in general tend to do a bad job at it or something along those lines etc.
I think color can make reading faster and easier, it's why syntax highlighting exists.
> default color choices assume dark terminal
Unless you’re using the 24bit color extensions, the default color choices are pretty abstract: if they are readable in one color scheme and unreadable in another, the problem is in the color scheme’s selection of colors.
Unless you’re using the 24bit color extensions, the default color choices are pretty abstract: if they are readable in one color scheme and unreadable in another, the problem is in the color scheme’s selection of colors.
In my experience most default terminal colorschemes are rather poor. You can't even make the seemingly obvious assumption that light colors have good contrast against "black" and that dark colors have good contrast against "white".
Blue on black is typically very bad.
Blue on black is typically very bad.
And yellow on white is completely unreadable...
> the problem is in the color scheme’s selection of colors.
Application can also set the background colours. If I "fix" things so that it will work well on a light background then it will be broken on applications that explicitly set a dark background.
Application can also set the background colours. If I "fix" things so that it will work well on a light background then it will be broken on applications that explicitly set a dark background.
For most cases this could probably be fixed by using a more abstract color scheme: rather than "red", "blue", "grey", and such, maybe "warn_0", "emphasis_0", "dull_0", etc.
I don't particularly hate colour, but I do find it annoying sometimes. I don't like my prompt to be overly loud but it has some colour to make it stick out. When programs output colour it makes it a bit harder to find where I typed the command. Again, though, this isn't the biggest of pain-points for me.
When most everything is b/w a splotch of color is very eye catching - but when your terminal always looks like a technicolor yawn a red error flashing by will be unnoticed.
> I think color can make reading faster and easier, it's why syntax highlighting exists.
Except you don't know the colour scheme of the terminal: is it a form of black text on white background, or white/green text on black background? If you decide to output something as (dark) blue text, how legible will it be?
As someone who has a black background, comments shown as dark blue make for difficult reading of many config files with Vim†.
† And another thing: when I invoke "vi" I want Vi: I do not want Vim. If I wanted Vim I would have typed in "vim". Having "vi" call Vim is a major pet peeve of mine: have to change that silly default in most distros nowadays.
Except you don't know the colour scheme of the terminal: is it a form of black text on white background, or white/green text on black background? If you decide to output something as (dark) blue text, how legible will it be?
As someone who has a black background, comments shown as dark blue make for difficult reading of many config files with Vim†.
† And another thing: when I invoke "vi" I want Vi: I do not want Vim. If I wanted Vim I would have typed in "vim". Having "vi" call Vim is a major pet peeve of mine: have to change that silly default in most distros nowadays.
This is why I think that every terminal color scheme should just have the right contrast for all colors with the default background. There are 16 colors and these days terminals are pretty much exclusively used for text, so why does your color scheme have a color that is illegible on the default background?
I understand that all bets are off if the application starts mixing and matching background colors, but there's no reason why your dark blue can't just be a little lighter.
(To be clear, I'm not blaming you for this, a lot of built-in color schemes have problems like this.)
I understand that all bets are off if the application starts mixing and matching background colors, but there's no reason why your dark blue can't just be a little lighter.
(To be clear, I'm not blaming you for this, a lot of built-in color schemes have problems like this.)
There are 256^3 colors.
Okay, well, true color mode is definitely a problem. But that's so obviously disrespectful that I don't think that you're going to get people who are using that on board with this new standard.
> As someone who has a black background, comments shown as dark blue make for difficult reading of many config files with Vim.
:set background=dark should fix that.
:set background=dark should fix that.
This is true, and it is also a fact exclusive to dark blue on black, solvable by not using dark blue ever. For any other color, it is easy unless it is the same color as the background.
> it is also a fact exclusive to dark blue on black, solvable by not using dark blue ever.
Try yellow on white.
(Dark blue on white is quite usable.)
Try yellow on white.
(Dark blue on white is quite usable.)
Last time I used Slackware, entering 'vi' still invoked elvis, a sufficiently minimal vi clone.
Vim was there too, under 'vim'.
Vim was there too, under 'vim'.
And FreeBSD and OpenBSD supply nvi as their vi.
In contrast, there are plenty of people that push this as a handy default. It's all over the place and sneaks in via all sorts of routes -- very unfortunately for those people who want vi to invoke something that is closer to genuine Joy vi than VIM and NeoVIM are, even in their "compatible" modes.
Just one example is the default yashrc that is used by the Watanabe shell: https://github.com/magicant/yash/blob/trunk/share/initializa...
(Yes, this is the default, in the absence of a yashrc file, not the sample yashrc file.)
In contrast, there are plenty of people that push this as a handy default. It's all over the place and sneaks in via all sorts of routes -- very unfortunately for those people who want vi to invoke something that is closer to genuine Joy vi than VIM and NeoVIM are, even in their "compatible" modes.
Just one example is the default yashrc that is used by the Watanabe shell: https://github.com/magicant/yash/blob/trunk/share/initializa...
(Yes, this is the default, in the absence of a yashrc file, not the sample yashrc file.)
I think color can make reading faster and easier, it's why syntax highlighting exists.
Not everyone likes or wants syntax highlighting. Personally I find it distracting at best and often actively hostile to being able to read the code (dark blue on black for comments!?)
http://www.linusakesson.net/programming/syntaxhighlighting/
Not everyone likes or wants syntax highlighting. Personally I find it distracting at best and often actively hostile to being able to read the code (dark blue on black for comments!?)
http://www.linusakesson.net/programming/syntaxhighlighting/
Doesn't this just mean you're using a suboptimal syntax theme? There a million out there with sufficient color contrast, there's no reason not to use one.
> I'd love to hear good reasoning why using color by default is bad.
About 1 in 12 men and about 1 in 200 women have some kind of color vision deficiency. Most commonly they have difficulty distinguishing green and red*. The default color choices essentially never account for this.
* Yes this does mean traffic lights are a problem. Fortunately for Americans, the red light is either far left or on top.
About 1 in 12 men and about 1 in 200 women have some kind of color vision deficiency. Most commonly they have difficulty distinguishing green and red*. The default color choices essentially never account for this.
* Yes this does mean traffic lights are a problem. Fortunately for Americans, the red light is either far left or on top.
If a color blind person can't distinguish between a green letter and a red letter, how does disabling color so both the green letter and the red letter are white help? If it mattered that you weren't able to distinguish between them, now nobody can. If it didn't, then the point's moot.
Precisely. This is only an issue if the _only_ difference between an error and success message is the colour.
As long as the information is communicated other ways as well, the colour is just a helpful thing for discriminating the messages and the loss of it by someone that’s colour blind, using a terminal with a configuration that doesn’t allow colour, or even just is sitting somewhere the sun is shining on their monitor and making colours hard to differentiate is… inconsequential.
As long as the information is communicated other ways as well, the colour is just a helpful thing for discriminating the messages and the loss of it by someone that’s colour blind, using a terminal with a configuration that doesn’t allow colour, or even just is sitting somewhere the sun is shining on their monitor and making colours hard to differentiate is… inconsequential.
> This is only an issue if the _only_ difference between an error and success message is the colour.
Except that a color bind person doesn't see monochrome, they see color, but perceive it differently. So the color palette problem isn't confined to only red and green, but also to other colors, because the spectrum as a whole is distinguished differently. Also, red/green color deficiency, while the most common, isn't the only kind of color blindness.
Except that a color bind person doesn't see monochrome, they see color, but perceive it differently. So the color palette problem isn't confined to only red and green, but also to other colors, because the spectrum as a whole is distinguished differently. Also, red/green color deficiency, while the most common, isn't the only kind of color blindness.
Terminals fortunately make it quite easy to map the basic 8 colors to whatever you like. There are very few people who can’t select 8 mutually distinguishable colours. They could even choose shades of grey!
This is an argument against using 256-color or true color though.
This is an argument against using 256-color or true color though.
No it isn't. The 256 colour system is based upon a palette, too. Indeed, in almost all terminal emulators it is the same palette as the AIXTerm 16 colour system, which just uses its first 16 entries. (They could be theoretically two different palettes. I know of no terminal emulator author who has implemented it this way. I thought of doing so, but even I didn't.)
> I'd love to hear good reasoning why using color by default is bad.
Your color choices might not align with the user's color scheme. Might be necessary to further process the output which means someone has to strip out the escape codes.
Your color choices might not align with the user's color scheme. Might be necessary to further process the output which means someone has to strip out the escape codes.
> Your color choices might not align with the user's color scheme
Then, just use the user's color scheme? This is an argument against using 256-color or terminal RGB, not against color altogether.
Then, just use the user's color scheme? This is an argument against using 256-color or terminal RGB, not against color altogether.
But that would be a shame to deprive 99.9% of your users from a colored output because some guy decided to remap red to green and black to blue.
But ANSI escape codes let you output colors by name, like “red” and “yellow”. If that doesn't align with their color scheme, then that's on them.
Welcome to the 21st century!
Your ship has sailed.
Unfortunately, the idea that one can set "solarized" colours, where the palette for the 16 AIXTerm colours is nothing like the AIXTerm colour set, has long since taken root in many people's minds, including, ironically, the minds of people who use this to turn off colourization by setting the AIXTerm 16 colour palette to various shades of grey.
Your ship has sailed.
Unfortunately, the idea that one can set "solarized" colours, where the palette for the 16 AIXTerm colours is nothing like the AIXTerm colour set, has long since taken root in many people's minds, including, ironically, the minds of people who use this to turn off colourization by setting the AIXTerm 16 colour palette to various shades of grey.
Please make them respect TERM=dumb first, then consider doing non-standard environment variables after that.
I am in agreement that colors by default, if used judiciously, are good. Disabling them by default seems like minority appeasement. If there are people who don't like colors, they should arrange for their own configurations to their terminal globally rather than have everyone else bend to their will.
Secondly, we don't need to respect this new flag for no color because most programs already disable their color output if they detect absence of a real tty by isatty(). So people who want to enforce no colors for all programs should either find a hack to put the running program under illusion, or just pipe output throught cat which will do it anyways. There is no point in having more unnecessary standards that will never realistically be complied with.
Secondly, we don't need to respect this new flag for no color because most programs already disable their color output if they detect absence of a real tty by isatty(). So people who want to enforce no colors for all programs should either find a hack to put the running program under illusion, or just pipe output throught cat which will do it anyways. There is no point in having more unnecessary standards that will never realistically be complied with.
Because no one deserves the onus of the opt-out, least of all the colorblind.
As has been mentioned multiple times in the thread, color schemes are highly configurable. It doesn't seem like it would be very hard to put together 16 colors that are easily distinguishable by the colorblind.
Isn't the real problem that these escape codes mess up the parsing of the output?
Color can definitely aid in understanding when it’s used with consistency. When it’s inconsistent, it becomes an impediment to understanding. The terminal is a place where you have lots of different small tools that you are using in conjunction. Even if each author uses color with consistency in their tool, the full collection of tools will be inconsistent with one another.
A hypothetical example: imagine syntax highlighting where strings are green, function names are blue, and comments are gray when you’re inside a function definition… but strings are green, function names are red, and comments are gray when you’re inside a lambda/closure/anonymous function definition… but strings are gray, function names are red, and comments are a syntax error when you’re in a string interpolation expression. In the terminal, each of those different contexts is likely to be a different tool. The author of the lambda highlighter arguably made a non-standard choice but they close PRs about this issue with “wontfix” because it invites too much bikeshedding. The author of the “string interpolation” tool wanted their tool to differentiate between the template/parent string and a string that happens to be part of the expression being interpolated. The string interpolation tool’s author has a good reason for their choice and their tool is very consistent about it, it even has a black magick regex incantation that gets arbitrarily nested cases correct. Each author has a good point and they’re all internally consistent, but when you are plugging them all together into a general purpose highlighter it still ends up inconsistent for you.
Or a real-world example: at the machining workshop, we have a painting cabinet filled with spray cans and paint tins of different bases. We don’t paint our products - that cabinet exists because whenever a new set of tools is brought to the shop, we paint all the flathead screwdriver handles yellow, all the Phillips-head screwdriver handles red, the Allen keys get a red band if they’re Imperial, a blue band if they’re metric, the wrenches likewise get red for Imperial, blue for metric, and so on. The standardized colors make it much easier to grab the right tool quickly, but we can’t rely on tool manufacturers to all globally standardize on colors since some of them have other constraints that we don’t care about (if they manufacture insulated screwdrivers for electricians as well, they will often reserve both yellow and red because “yellow and red two-tone” is the color scheme for insulated screwdrivers, so their non-insulated screwdrivers will be green for flathead, blue for Phillips - or purple for flathead, green for Phillips - etc). The terminal is an even more extreme example since it’s rare to get a whole set of terminal utilities from the same author, so all your number 2 Phillips would be from a different manufacturer than your number 1 Phillips. Also the terminal is sort of like a workshop where all the tools, even the screwdrivers, can be machine-mounted so maybe you want no paint on the handles because otherwise it rubs off on the chuck and the build-up messes up your tolerances over time, or something.
A hypothetical example: imagine syntax highlighting where strings are green, function names are blue, and comments are gray when you’re inside a function definition… but strings are green, function names are red, and comments are gray when you’re inside a lambda/closure/anonymous function definition… but strings are gray, function names are red, and comments are a syntax error when you’re in a string interpolation expression. In the terminal, each of those different contexts is likely to be a different tool. The author of the lambda highlighter arguably made a non-standard choice but they close PRs about this issue with “wontfix” because it invites too much bikeshedding. The author of the “string interpolation” tool wanted their tool to differentiate between the template/parent string and a string that happens to be part of the expression being interpolated. The string interpolation tool’s author has a good reason for their choice and their tool is very consistent about it, it even has a black magick regex incantation that gets arbitrarily nested cases correct. Each author has a good point and they’re all internally consistent, but when you are plugging them all together into a general purpose highlighter it still ends up inconsistent for you.
Or a real-world example: at the machining workshop, we have a painting cabinet filled with spray cans and paint tins of different bases. We don’t paint our products - that cabinet exists because whenever a new set of tools is brought to the shop, we paint all the flathead screwdriver handles yellow, all the Phillips-head screwdriver handles red, the Allen keys get a red band if they’re Imperial, a blue band if they’re metric, the wrenches likewise get red for Imperial, blue for metric, and so on. The standardized colors make it much easier to grab the right tool quickly, but we can’t rely on tool manufacturers to all globally standardize on colors since some of them have other constraints that we don’t care about (if they manufacture insulated screwdrivers for electricians as well, they will often reserve both yellow and red because “yellow and red two-tone” is the color scheme for insulated screwdrivers, so their non-insulated screwdrivers will be green for flathead, blue for Phillips - or purple for flathead, green for Phillips - etc). The terminal is an even more extreme example since it’s rare to get a whole set of terminal utilities from the same author, so all your number 2 Phillips would be from a different manufacturer than your number 1 Phillips. Also the terminal is sort of like a workshop where all the tools, even the screwdrivers, can be machine-mounted so maybe you want no paint on the handles because otherwise it rubs off on the chuck and the build-up messes up your tolerances over time, or something.
Don't we already have a standard for programs to behave differently depending on whether the output is meant for human consumption or not? e.g ls will not output colors when piped into something. Looks like its the isatty() function?
Beyond that this is a feature that some people want i guess.. I could ask every website to give me a NO_COLOR mode as well, but they don't. Instead you can greyscale at the OS level or the terminal emulator level if you need it.
Beyond that this is a feature that some people want i guess.. I could ask every website to give me a NO_COLOR mode as well, but they don't. Instead you can greyscale at the OS level or the terminal emulator level if you need it.
> I could ask every website to give me a NO_COLOR mode as well, but they don't.
Perhaps more websites than you realise: I use the reader view whenever I can, which is a little bit like $NO_COLOR for websites.
Browsers also tend to widely have support for disabling style sheets and support for overrides, and wide support is more important than theoretical solutions.
I do think it would be great if terminals had broad support for this kind of accessibility feature, but they don’t, and I think adding it is much harder than you think.
> Instead you can greyscale at the OS level or the terminal emulator level if you need it.
This doesn’t work very well in practice unfortunately because the intensity differs so widely and my terminal settings don’t help when I have to look at someone else’s screen.
So while we wait for operating systems and terminal emulators to add more support for the disabled, maybe if you don’t mind, the next time you think about calling puts() with some color-codes in it you could just pretty-please check if $NO_COLOR is set?
Perhaps more websites than you realise: I use the reader view whenever I can, which is a little bit like $NO_COLOR for websites.
Browsers also tend to widely have support for disabling style sheets and support for overrides, and wide support is more important than theoretical solutions.
I do think it would be great if terminals had broad support for this kind of accessibility feature, but they don’t, and I think adding it is much harder than you think.
> Instead you can greyscale at the OS level or the terminal emulator level if you need it.
This doesn’t work very well in practice unfortunately because the intensity differs so widely and my terminal settings don’t help when I have to look at someone else’s screen.
So while we wait for operating systems and terminal emulators to add more support for the disabled, maybe if you don’t mind, the next time you think about calling puts() with some color-codes in it you could just pretty-please check if $NO_COLOR is set?
Reader view is a giant hack by the browser that more or less ignores what styles the webpage has set.
A better match would be print (view) where the website does get to specify the style (although some browsers add their own heuristics because most websites don't).
A better match would be print (view) where the website does get to specify the style (although some browsers add their own heuristics because most websites don't).
A lot of people here are attributing semantics to the article that I don't believe it has claimed.
To me this simply reads, "If your application deals with colour, consider your user, and please also consider this standard".
In particular the line "If your software outputs colour by default, please consider not doing so", on one hand comes across as opinionated, on the other hand I mostly interpret this as a call to not have coloured output as a default without having first considered an easy way to disable it, which is sensible.
I like colours in my terminal, and have included them in most of my non-trivial work; I have also added NO_COLOR because I think it's a nice informal standard, but more importantly I support the --color=<auto|never|always> GNU standard.
The part where I lack a bit is the customisability; I'm not too sure how to use terminal themes, so I have been using absolute colour sequences instead. I need to look that up...
To me this simply reads, "If your application deals with colour, consider your user, and please also consider this standard".
In particular the line "If your software outputs colour by default, please consider not doing so", on one hand comes across as opinionated, on the other hand I mostly interpret this as a call to not have coloured output as a default without having first considered an easy way to disable it, which is sensible.
I like colours in my terminal, and have included them in most of my non-trivial work; I have also added NO_COLOR because I think it's a nice informal standard, but more importantly I support the --color=<auto|never|always> GNU standard.
The part where I lack a bit is the customisability; I'm not too sure how to use terminal themes, so I have been using absolute colour sequences instead. I need to look that up...
I have a love-hate relationship with colors in technical environments. When used properly, they are awesome. For example, I have custom syntax rules for assembly that highlight each register in different colors as well as highlighting instructions based on type. This allows me to visually see dependency chains in disassembler output without having to type a single key.
On the other hand, every single editor from Vim to full blown IDEs has an absolutely braindead idea of what syntax highlighting should be.
Some keywords are useless noise (public, final, const, struct) while other keywords are more important - but usually they are all behind a single syntax rule called "keyword". I want to configure each one individually so I can visually scan code faster. IntelliJ has the right idea with semantic highlighting and I think every editor these days has a rainbow parentheses plugin that helps deciphering long expressions.
Personally, I've fixed this with a few Vim keybinds allowing me to dynamically highlight things that are important at the moment.
For non-interactive use I either use Vim as a pager or pipe to a small script which highlights what I want to see.
On the other hand, every single editor from Vim to full blown IDEs has an absolutely braindead idea of what syntax highlighting should be.
Some keywords are useless noise (public, final, const, struct) while other keywords are more important - but usually they are all behind a single syntax rule called "keyword". I want to configure each one individually so I can visually scan code faster. IntelliJ has the right idea with semantic highlighting and I think every editor these days has a rainbow parentheses plugin that helps deciphering long expressions.
Personally, I've fixed this with a few Vim keybinds allowing me to dynamically highlight things that are important at the moment.
For non-interactive use I either use Vim as a pager or pipe to a small script which highlights what I want to see.
In Vim it's often relatively easy to fix these kind of issues and tweak things to your liking; e.g. "syn clear cStructure" to clear just the highlight for struct, union, and enum keywords in C (and not anything else), "syn clear javaScopeDecl" to disable the scope declarations in Java, etc.
Details differ per language; but most syntax files declare fine-grained syntax rule which are then linked to "Keyword" highlight or whatnot later, but there's nothing preventing you from clearing the fine-grained syntax rules (or just defining your own).
Details differ per language; but most syntax files declare fine-grained syntax rule which are then linked to "Keyword" highlight or whatnot later, but there's nothing preventing you from clearing the fine-grained syntax rules (or just defining your own).
See also https://bixense.com/clicolors/ for CLICOLOR and CLICOLOR_FORCE env variables. In my applications and CLI libraries (like Rust's clap), I support both.
FORCE_COLOR is a de facto variable without a de facto meaning, so I don't bother to support it.
FORCE_COLOR is a de facto variable without a de facto meaning, so I don't bother to support it.
Yeah this is an earlier and better standard. It's really disappointing that someone felt the need to push an incompatible and worse alternative.
I'll give them the benefit of the doubt that they simply didn't search for existing solutions, but when it was pointed out to them they really should have said "ok yeah you should use that".
Instead it isn't even mentioned on their website.
I'll give them the benefit of the doubt that they simply didn't search for existing solutions, but when it was pointed out to them they really should have said "ok yeah you should use that".
Instead it isn't even mentioned on their website.
This is interesting, and standardization is great. but I'm also curious why they cared. Most CLI tools will not output color when piped to something else, so I'm curious if this was created to fix a peeve or if there's other practical benefits.
They also won't output stuff like progress bars, width-aware content, and may change other behavior. It would also annoying to pipe everything.
NO_FOO variables seem to me like bad design: it makes it hard to override/explicity ask for FOO. In general, I think allowing a set of options like FOO=always,never,auto gives a lot more flexibility and extensibility.
Where's the fun in that? Use NO_FOO=enable,disable to maximize ambiguity.
To increase confusion the variable name should contain the verb as well:
NO_COLOR_DISABLED=enabled
Yes, it would be better if colour were opt-in.
I'm not anti-color in general, but I think its use should be reserved to where it is truly helpful. Often it feels like it's value is mostly just superficial pizazz. Grep highlighting matches is one of the examples where color is very helpful, but even there I think bold would work just as well without potentially running into any colorscheme issues.
Color is fine with me, but I'd love to have a standard way to disable emoji.
Yes please. Excessive use of colors, emojis and text in the terminal is one of the main reasons that I hate working with JS CLIs these days.
While we're at it, can we get a "TITE_INHIBIT" or "NO_SECOND_SCREEN"? I must be the only one, but I hate having stuff up on my screen, like from a man page or editing a file, then going back to the command-line and having it disappear. Loved "tite_inhibit" in xterm, but I've moved on to wezterm and I'm tired of dealing with custom termcaps.
I don’t know wezterm but in xterm you can make a button toggle the second screen, and this can be nice for switching between the manual page you were just looking at and the line you are typing into.
I also prefer this to having a fucked up scrollback.
I also prefer this to having a fucked up scrollback.
I think that varies case by case. Sometimes "intermediate" output should disappear because it's less interesting than what I had before. Sometimes it should not disappear as you write. To implement that the shell prompt would need to contain a special esacape sequence as a marker and then the user can manually hide the output of the last command. Or to make it even more fancy: Hide and unhide output of any previous command.
Try LESS='-X'
It is surprising that, while it's obvious that the website was built carefully, it didn't occur to the author to articulate the rationale for this whole campaign. I suppose in the author's mind, this site's audience are people for whom this is self-evident. Still bad form for a public request to not provide reasoning.
If you care about this, use a desaturated (or even monochrome) color scheme for your terminal. If you encounter software that tries to use 256/true color, use a terminal that doesn't support it (or that can disable it).
I use a desaturated theme for coding: bg #f6f6f3, fg #303030, keyword #303060, etc (and a dark variant for the late sessions). I have a little bit more saturation in the terminal (eg #3465a4 for blue) but it's definitely on the toned down side, compared e.g. to the xterm or Terminal.app defaults.
Remember when MS Windows allowed you to change the color of every single UI element? Some of these color schemes were really beautiful. We should go back to user-themeable UIs.
I use a desaturated theme for coding: bg #f6f6f3, fg #303030, keyword #303060, etc (and a dark variant for the late sessions). I have a little bit more saturation in the terminal (eg #3465a4 for blue) but it's definitely on the toned down side, compared e.g. to the xterm or Terminal.app defaults.
Remember when MS Windows allowed you to change the color of every single UI element? Some of these color schemes were really beautiful. We should go back to user-themeable UIs.
I wonder if people who like desaturated color schemes for code haven't set their monitors too bright. Or at least too bright for my tastes.
I keep my monitors on as low brightness as i can without losing color and I end up using high saturation themes to make things more clear.
I keep my monitors on as low brightness as i can without losing color and I end up using high saturation themes to make things more clear.
Desaturated colors are a good middle ground between monochrome and fruit salad, especially for text.
My other screen is a Thinkpad X230 and there's no definition of "too bright" that fits it, even at max brightness.
My other screen is a Thinkpad X230 and there's no definition of "too bright" that fits it, even at max brightness.
Why not implement a program that reads from stdin, strips any ansi color, and writes to stdout?
Interactive programs wouldn't work very well with this idea. And then you're what, stuck with always piping through some anti-color application each time too? Seems cumbersome.
Those problems are solvable with a PTY. Like how ‘screen’ and ‘tmux’ work.
I already have some code in my own shell to wrap everything in a PTY (ironically to add colour: highlight stderr in red) but I could just as easily do the opposite and strip all colour escape sequences.
I already have some code in my own shell to wrap everything in a PTY (ironically to add colour: highlight stderr in red) but I could just as easily do the opposite and strip all colour escape sequences.
Most programs disable color output when piped, so just piping to cat already accomplishes this.
[deleted]
It seems like most of the complaints that people have with color could be resolved by a few simple rules:
* All color schemes shall have the 15 colors that are not the background contrast well with the background.
* Terminal applications shall not specify white or black as the foreground color.
* Terminal applications shall not specify the background color.
* Terminal applications shall not output escape codes when piping or otherwise being used programmatically.
TFA seems to have pretty serious issues with color in general, so I'm curious to know from those here if the rules above would address your complaints or if there's something more going on that I'm just missing.
* All color schemes shall have the 15 colors that are not the background contrast well with the background.
* Terminal applications shall not specify white or black as the foreground color.
* Terminal applications shall not specify the background color.
* Terminal applications shall not output escape codes when piping or otherwise being used programmatically.
TFA seems to have pretty serious issues with color in general, so I'm curious to know from those here if the rules above would address your complaints or if there's something more going on that I'm just missing.
They would do nothing for me.
High-color terminals and apps beak out of the 16-color limit. Changing my “color theme” when someone wants to look at my screen sounds like more work than typing NO_COLOR=1. If I need to look at someone else’s screen what can I possibly do about their choice of colors and terminal emulators?
High-color terminals and apps beak out of the 16-color limit. Changing my “color theme” when someone wants to look at my screen sounds like more work than typing NO_COLOR=1. If I need to look at someone else’s screen what can I possibly do about their choice of colors and terminal emulators?
Colors are useful. There's a reason many code editors have color syntax highlighting - it conveys information and is easy to work with. Most terminal colors in my experience aren't just for "looks", they're for displaying information in a clear and compact way.
If you prefer no colors in your environment that's fine and you can probably configure it that way, but I don't think no color as a global default makes sense.
If you prefer no colors in your environment that's fine and you can probably configure it that way, but I don't think no color as a global default makes sense.
Why doesn't it make sense?
I also don't agree with the assumption that color carries information. Or rather, that you use it as such. The visual system uses different areas as markers. Color/high-lighting makes it easier to e.g. jump to the beginning of a function. But it would confuse you when used to convey semantics, e.g. when using color to distinguish between "if" as the start of a conditional statement and as an identifier. At least, that's what the Stroop task suggests might happen.
I also don't agree with the assumption that color carries information. Or rather, that you use it as such. The visual system uses different areas as markers. Color/high-lighting makes it easier to e.g. jump to the beginning of a function. But it would confuse you when used to convey semantics, e.g. when using color to distinguish between "if" as the start of a conditional statement and as an identifier. At least, that's what the Stroop task suggests might happen.
[deleted]
If you do end up emitting color by default, please at least make it contingent on isatty() - maybe the user can override that but I rarely want it when redirecting.
As a counter-example, I hate that piping to less will generally strip colour unless I tell both less and the command to really output color.
It would be nice to be able to have something like 'colorless <command I want to pipe to less>', and the 'colorless' command will run the given program, fake a TTY so that the isatty() check passes and it outputs color, then pipe it into the pager.
Unfortunately, calling it colorless would be exactly the wrong name for it!
Unfortunately, calling it colorless would be exactly the wrong name for it!
Check out lesstty from https://github.com/kilobyte/colorized-logs.
(Or https://github.com/jwilk/pagerboy, which supports pagers other than less.)
(Or https://github.com/jwilk/pagerboy, which supports pagers other than less.)
Thank you! That looks very useful.
The associated program 'ansi2txt' could also solve a similar problem for me from the other way round: I tend to have grep aliased to 'grep --color=always', simply because often I'm going to pipe the results to 'less' and I still want the colors. But this sometimes trips me up if I have a series of greps: The first grep output has color codes, making the followup greps fail. If grep could be made to strip out color codes prior to running, everything would work just as expected.
In general, if you're running a series of connected commands, it's only the last one that you want to get the colors from, with the special case exception of when the last command is 'less' - in which case, the next-to-last one should keep the colors. All ways that make this happen automatically are useful!
The associated program 'ansi2txt' could also solve a similar problem for me from the other way round: I tend to have grep aliased to 'grep --color=always', simply because often I'm going to pipe the results to 'less' and I still want the colors. But this sometimes trips me up if I have a series of greps: The first grep output has color codes, making the followup greps fail. If grep could be made to strip out color codes prior to running, everything would work just as expected.
In general, if you're running a series of connected commands, it's only the last one that you want to get the colors from, with the special case exception of when the last command is 'less' - in which case, the next-to-last one should keep the colors. All ways that make this happen automatically are useful!
Considering less is more, wouldn't colorless be exactly the right name?
My favourite dumb about colour application is Terraform. So many logs from GH Actions have useless ANSI escape sequences in them.
They seem to be using https://github.com/mitchellh/colorstring/blob/master/colorst... instead of isatty and curses and terminfo.
Ah, thank you! A place for me to start digging, namely, how do I make c.Disable true. I suspect there's an easy flag for it, but still :/
> It should be up to the user whether color is used, not the software author.
I don't understand this sentiment. As well say "it should be up to the user what the function of the software is, not the software author". If you don't like what a particular piece of software is doing, fork it and fix it, or replace it.
(To be clear -- I support the idea of `NO_COLOR` and other standards generally, and I strive to implement relevant standards when I can. I just think the above sentiment is bananas).
I don't understand this sentiment. As well say "it should be up to the user what the function of the software is, not the software author". If you don't like what a particular piece of software is doing, fork it and fix it, or replace it.
(To be clear -- I support the idea of `NO_COLOR` and other standards generally, and I strive to implement relevant standards when I can. I just think the above sentiment is bananas).
From time to time I have to use Powershell and its console colors are driving me nuts. I find some of the output in the default setting to be near unreadable, personally. This on top of its weird syntax make it even more annoying. There isn't any built-in option to reset that, unless you take the time to write a script to reset everything.
This kind of one-off setting like in the OP would make it a tad more usable.
This kind of one-off setting like in the OP would make it a tad more usable.
Chalk[0][1] maintainer here. We've gone over this, uh... call to arms? a number of times before. AMA.
[0] https://github.com/chalk
[1] https://npmjs.org/package/chalk
[0] https://github.com/chalk
[1] https://npmjs.org/package/chalk
Why not add env("NO_COLOR") to it as an equivalent of FORCE_COLOR=0?
Because we've had 5nor 6 of these standards and it becomes unclear which one should take precedence. If FORCE_COLOR=1 and NO_COLOR is defined, which one wins?
FORCE_COLOR was the first we had found that was also present in other Unix utilities and thus the one that won.
FORCE_COLOR was the first we had found that was also present in other Unix utilities and thus the one that won.
I'm a bit late, but perhaps you could write the no-color website maintainer, and ask to link to similar projects? Then we could see all options to disable or forcibly enable color in one glance.
The examples seem to encourage hard-coding specific colours, and includes examples that are unreadable on a light background.
chalk.bgHex('#DEADED').underline('Hello, world!')We don't encourage it, we just supply the functionality. There's no fix here - terminal colors are inherently environment-unaware aside from the basic 16 (8 dark, 8 light).
Why should this be the writer's responsibility instead of the shell? Unless one is bandwidth-constrained, shouldn't the protocol be for programs to emit data as rich as possible and it be the interpreter's responsibility to format it in a way the user can understand?
The primary usecase for no color, in my opinion, is for running software on CI/CD and other automated systems. Sometimes you want to track logs or alert on certain output and you don't want a bunch of garbage characters that can't be displayed on those systems.
Highly devoted standard that makes sense…and this is coming from someone who does not mind color…
[deleted]
Doesn’t it make more sense to have CLICOLOR set by default in most environments and distros and respect that? That’s already been supported by most standard tools for decades.
Also, please don't barf random emojis on the terminal.
Is behaviour defined for programs with a `--color=always` flag set in combination with NO_COLOR? I'd assume `--color=always` takes precedence
Yes; as you assume, a compliant program disables color by default when NO_COLOR is set but a command line flag, etc, could turn it back on.
my bias/defaults:
screen? white on black. give users easy option of overriding the text colors, styles and fonts
paper? black on white
wise rule of thumb. any exceptions should be a clear net win in the context/domain
screen? white on black. give users easy option of overriding the text colors, styles and fonts
paper? black on white
wise rule of thumb. any exceptions should be a clear net win in the context/domain
Are environment variables the right place for such an option?
This is effectively config. Should we export all of /etc/* into environment variables too? One variable per configurable thing?
This is effectively config. Should we export all of /etc/* into environment variables too? One variable per configurable thing?
Expanded:
2022: https://news.ycombinator.com/item?id=30483417 (201 comments)
2019: https://news.ycombinator.com/item?id=21171274 (9 comments)
2018: https://news.ycombinator.com/item?id=16322116 (53 comments)
2022: https://news.ycombinator.com/item?id=30483417 (201 comments)
2019: https://news.ycombinator.com/item?id=21171274 (9 comments)
2018: https://news.ycombinator.com/item?id=16322116 (53 comments)
anotherpaulg(1)
Sounds broken by spec without a false/disable value or values defined. It says to always assume true for any non-empty string, which would include things like "no", "off", "false", "0", etc.
It's a common standard for UNIX environment variables to be treated this way, and it greatly simplifies the logic needed to handle the value. Here's how this can be simply implemented in Python:
if os.environ.get("NO_COLORS"): ...
if [ "$NO_COLORS" ]; ...
if [ "${NO_COLORS:-}" ]; ...
> By adopting this standard, users that prefer to have plain, non-colored text output can export NO_COLOR=1 to their shell’s environment and automatically disable color by default in all supported software.
If your software outputs color by default, please consider not doing so. If you insist, please implement this standard to make it easy for your users to disable color and then add your software to this list by submitting a pull request.
I have tried NO_SLOPPY_GRAMMAR=1, but I still get meaningless text about users adopting a standard and me not outputting color if my software does.
I have tried NO_SLOPPY_GRAMMAR=1, but I still get meaningless text about users adopting a standard and me not outputting color if my software does.
And I tried NO_POINTLESS_SNARK=1, and yet here we both are.
Quite opinionated for not giving additional 𝘃𝗮𝗹𝗶𝗱 arguments.
Also the arguments regarding colorblind crowd being unable to distinguish colors are weak, as accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means, so that everybody has their chance to understand it (e.g. setting links in a distinguished color and underlined).
Using colors (e.g. rkhunter malware report with its hundreds of checks uses green for success and red for warnings/errors) is not only enjoyed by many, but a relieve for ADDeez.
Whoever doesn't want to have color, just pipe anything through ansi2txt; https://askubuntu.com/questions/984357/how-do-i-pipe-each-co...