No_color

by ingve • 3 years ago

289 201 3 years ago

treve• 3 years ago

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.

drewtato• 3 years ago

They also won't output stuff like progress bars, width-aware content, and may change other behavior. It would also annoying to pipe everything.

chroma2• 3 years ago

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.

jeroenhd• 3 years ago

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.

comradesmith• 3 years ago

That’s still up to the developer of the producer to implement

esprehn• 3 years ago

Piping to cat won't work for an interactive tool though.

ktpsns• 3 years ago

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).

nerdponx• 3 years ago

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?

n2d4• 3 years ago

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.

aidenn03• 3 years ago

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.

DSMan195276• 3 years ago

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.

rice7th• 3 years ago

Yeah. If you don't like colors just diable them from the terminal.

noitpmeder• 3 years ago

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.

Waterluvian• 3 years ago

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.

chroma2• 3 years ago

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.

aumerle• 3 years ago

terminal emulators dont actually know this. Just think of executing something via ssh. In this case the primary foreground process is ssh.

TheRealPomax• 3 years ago

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.

slmjkdbtl• 3 years ago

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

geocar5• 3 years ago

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.

tedunangst• 3 years ago

Previously: https://news.ycombinator.com/from?site=no-color.org

jwilk2• 3 years ago

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)

adeon• 3 years ago

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.

bombcar• 3 years ago

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.

fiddlerwoaroof• 3 years ago

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.

arp2426• 3 years ago

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.

leni536• 3 years ago

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.

sodapopcan• 3 years ago

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.

drivingmenuts• 3 years ago

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.

shakow• 3 years ago

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.

aidenn03• 3 years ago

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.

bobbylarrybobby2• 3 years ago

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.

cratermoon2• 3 years ago

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.

burke• 3 years ago

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.

pie_flavor2• 3 years ago

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.

fwlr• 3 years ago

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.

rubicks• 3 years ago

Because no one deserves the onus of the opt-out, least of all the colorblind.

lolinder5• 3 years ago

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.

throw0101b• 3 years ago

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.

pie_flavor2• 3 years ago

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.

lolinder5• 3 years ago

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.)

bitwize2• 3 years ago

Last time I used Slackware, entering 'vi' still invoked elvis, a sufficiently minimal vi clone.

Vim was there too, under 'vim'.

arp2426• 3 years ago

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.

userbinator• 3 years ago

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/

bobbylarrybobby2• 3 years ago

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.

bigdict• 3 years ago

Isn't the real problem that these escape codes mess up the parsing of the output?

sarthak-ag• 3 years ago

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.

JdeBP10• 3 years ago

Please make them respect TERM=dumb first, then consider doing non-standard environment variables after that.

pcthrowaway• 3 years ago

Is behaviour defined for programs with a `--color=always` flag set in combination with NO_COLOR? I'd assume `--color=always` takes precedence

ksherlock• 3 years ago

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.

wyldfire• 3 years ago

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.

rocqua• 3 years ago

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.

joosters2• 3 years ago

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!

jsd1982• 3 years ago

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.

ericpruitt• 3 years ago

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"): ...

In POSIX shell:

    if [ "$NO_COLORS" ]; ...

or, when nounset is used:

    if [ "${NO_COLORS:-}" ]; ...

Adding sentinel values when you only need a true/false indicator just complicates things.

numbsafari• 3 years ago

Why not implement a program that reads from stdin, strips any ansi color, and writes to stdout?

taftster• 3 years ago

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.

hnlmorg2• 3 years ago

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.

aidenn03• 3 years ago

Most programs disable color output when piped, so just piping to cat already accomplishes this.

endgame• 3 years ago

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.

rippercushions• 3 years ago

Where's the fun in that? Use NO_FOO=enable,disable to maximize ambiguity.

serpix• 3 years ago

To increase confusion the variable name should contain the verb as well: NO_COLOR_DISABLED=enabled

kps8• 3 years ago

Yes, it would be better if colour were opt-in.

interfixus• 3 years ago

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.

EdwardDiego3• 3 years ago

And I tried NO_POINTLESS_SNARK=1, and yet here we both are.

deathless• 3 years ago

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).

epage• 3 years ago

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.

IshKebab• 3 years ago

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.

lolinder5• 3 years ago

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.

geocar5• 3 years ago

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?

jonhohle• 3 years ago

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.

slicktux• 3 years ago

Highly devoted standard that makes sense…and this is coming from someone who does not mind color…

olvy0• 3 years ago

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.

linsomniac• 3 years ago

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.

aib• 3 years ago

Try LESS='-X'

geocar5• 3 years ago

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.

usr1106• 3 years ago

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.

zaptheimpaler• 3 years ago

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.

geocar5• 3 years ago

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?

account425• 3 years ago

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).

EdwardDiego3• 3 years ago

My favourite dumb about colour application is Terraform. So many logs from GH Actions have useless ANSI escape sequences in them.

erik_seaberg• 3 years ago

They seem to be using https://github.com/mitchellh/colorstring/blob/master/colorst... instead of isatty and curses and terminfo.

EdwardDiego3• 3 years ago

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 :/

ruuda• 3 years ago

Color is fine with me, but I'd love to have a standard way to disable emoji.

endorphine• 3 years ago

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.

Eduard• 3 years ago

If your software outputs color by default, please consider not doing so.

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

p-e-w• 3 years ago

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.

Conscat• 3 years ago

Emacs is fine at screen reading in a terminal environment.

alpaca1282• 3 years ago

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.

vanous• 3 years ago

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.

arp2426• 3 years ago

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.

hulitu• 3 years ago

There is more accessability besides screen readers. Not all people are blind. Some people just want bigger fonts and better contrast.

mananaysiempre• 3 years ago

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.

blueflow2• 3 years ago

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.

tgv7• 3 years ago

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?

Kwpolska2• 3 years ago

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.

cerved• 3 years ago

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

anthk3• 3 years ago

       alias ls='ls -F'

quicksilver03• 3 years ago

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.

citrin_ru3• 3 years ago

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).

josteink2• 3 years ago

as accessibility best practices suggest to convey semantically relevant markup

You may have missed that this is about CLI applications, not web-pages.

yreg• 3 years ago

Accessibility is important for everyone, CLI users included. If you live long enough, you will depend on accessibility features yourself.

Simplicitas• 3 years ago

I stopped reading right after that silly comment - the world is full of colors!

brookst• 3 years ago

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.

usrbinbash• 3 years ago

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.

andreareina• 3 years ago

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".

FeepingCreature• 3 years ago

Sure, but that has a simple solution not even mentioned in this post: isatty(1)

ori_b2• 3 years ago

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?

riversflow• 3 years ago

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.

pessimizer• 3 years ago

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?

norir• 3 years ago

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.

awestroke• 3 years ago

Why not just change all colors to the same color (b/w) in your terminal emulator settings??

hnlmorg2• 3 years ago

That only works if applications stick to the default 16 colours. What grinds my gears is when applications use the 8 bit or 24 bit ansi escape codes for anything other than TUI graphics.

PhilipRoman• 3 years ago

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.

arp2426• 3 years ago

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).

olgeni• 3 years ago

Also, please don't barf random emojis on the terminal.

londons_explore• 3 years ago

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?

tpoacher2• 3 years ago

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

junon3• 3 years ago

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

kps8• 3 years ago

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!')

junon3• 3 years ago

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).

tgv7• 3 years ago

Why not add env("NO_COLOR") to it as an equivalent of FORCE_COLOR=0?

junon3• 3 years ago

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.

dmos62• 3 years ago

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.

rollcat2• 3 years ago

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.

nottorp• 3 years ago

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.

rollcat2• 3 years ago

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.

shadowgovt• 3 years ago

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?

aigoochamna• 3 years ago

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.

syngrog66• 3 years ago

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

naet• 3 years ago

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.

tgv7• 3 years ago

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.

No_color

Related Stories