[HN Gopher] No_color
___________________________________________________________________
No_color
Author : ingve
Score : 269 points
Date : 2023-05-27 21:25 UTC (1 days ago)
(HTM) web link (no-color.org)
(TXT) w3m dump (no-color.org)
| wyldfire wrote:
| 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 wrote:
| 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.
| joosters wrote:
| 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!
| jwilk wrote:
| Check out lesstty from
| https://github.com/kilobyte/colorized-logs.
|
| (Or https://github.com/jwilk/pagerboy, which supports
| pagers other than less.)
| joosters wrote:
| 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!
| anotherpaulg wrote:
| Off topic, but I asked my open source GPT coding app to update
| itself to conform to the NO_COLOR spec. So it did.
|
| You can see the chat transcript here:
|
| https://aider.chat/examples/no-color.html
| lolinder wrote:
| GPT stuff is so dominant in basically every other part of the
| site these days, I would really prefer that people not pull it
| in to completely unrelated threads.
| anotherpaulg wrote:
| Completely fair point. I was just happily surprised at how
| easy it was to add the support.
| self_awareness wrote:
| > self.console = Console(force_terminal=not pretty,
| no_color=not pretty)
|
| I don't think it's not a good idea to not use more
| negations so it's not more complicated to understand what's
| going on ;)
|
| (I think it's a good idea to use less negations to
| understand what's going on)
| shadowgovt wrote:
| 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?
| norir wrote:
| 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.
| ruuda wrote:
| Color is fine with me, but I'd love to have a standard way to
| disable emoji.
| endorphine wrote:
| 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.
| junon wrote:
| 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
| kps wrote:
| 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!')
| junon wrote:
| 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).
| Eduard wrote:
| > If your software outputs color by default, please consider not
| doing so.
|
| Quite opinionated for not giving additional valid 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...
| Simplicitas wrote:
| I stopped reading right after that silly comment - the world is
| full of colors!
| josteink wrote:
| > as accessibility best practices suggest to convey
| semantically relevant markup
|
| You may have missed that this is about CLI applications, not
| web-pages.
| yreg wrote:
| Accessibility is important for everyone, CLI users included.
| If you live long enough, you will depend on accessibility
| features yourself.
| josteink wrote:
| Sure.
|
| But CLI apps don't have markup, much less semantic markup.
|
| That was my point.
| p-e-w wrote:
| > 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.
| alpaca128 wrote:
| > 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.
| dumpsterdiver wrote:
| > 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.
| capableweb wrote:
| 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.
| dumpsterdiver wrote:
| > 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.
| capableweb wrote:
| 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".
| dumpsterdiver wrote:
| 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?
| funklute wrote:
| 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.
| dumpsterdiver wrote:
| > 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.
| funklute wrote:
| 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.
| hulitu wrote:
| There is more accessability besides screen readers. Not all
| people are blind. Some people just want bigger fonts and
| better contrast.
| jnovek wrote:
| 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.
| Conscat wrote:
| Emacs is fine at screen reading in a terminal environment.
| funklute wrote:
| 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?
| anthk wrote:
| Emacs has Emacspeak which works on everything.
| blueflow wrote:
| 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.
| JdeBP wrote:
| BRLTTY, for one, reads vcsa devices, which don't see CSI
| colour sequences at all, but are straightforward arrays of
| character+attribute pairs.
| galleywest200 wrote:
| > 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?
| blueflow wrote:
| I was someone trying to connect a linux pty with the
| espeak backend.
| [deleted]
| mananaysiempre wrote:
| > 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.
| JdeBP wrote:
| 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.
| vanous wrote:
| > 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.
| arp242 wrote:
| 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.
| tpoacher wrote:
| Presumably they're referring to CLI rather than TUI
| applications though.
| arp242 wrote:
| Maybe, not sure. I wouldn't quick to assume anything
| though - I could imagine at least some TUIs could
| possibly work quite well, perhaps with some minor setup.
| cumshitpiss wrote:
| [dead]
| quicksilver03 wrote:
| > 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_ru wrote:
| 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).
| anthk wrote:
| Use the Tango color scheme.
| kps wrote:
| 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.)
| tgv wrote:
| 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?
| cerved wrote:
| 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
| hakre wrote:
| it depends on the invocation, and by default it checks for
| tty or not. the aliasing often does not touch this.
|
| example alias: $ alias ls ls='ls
| --color=tty'
|
| and from ls(1): "With --color=auto, ls emits color codes
| only when standard output is connected to a terminal. The
| LS_COLORS environment variable can change the settings. Use
| the dircolors command to set it."
|
| ("tty" and "if-tty" are the same as "auto")
| anthk wrote:
| alias ls='ls -F'
| Kwpolska wrote:
| > 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.
| tgv wrote:
| > 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.
| Kwpolska wrote:
| 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
| assbuttbuttass wrote:
| > 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...
| geocar wrote:
| > 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: NO_COLOR= command
|
| is fine.
|
| > 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
| brookst wrote:
| 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.
| [deleted]
| dmos62 wrote:
| 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.
| slicktux wrote:
| Highly devoted standard that makes sense...and this is coming
| from someone who does not mind color...
| tedunangst wrote:
| Previously: https://news.ycombinator.com/from?site=no-color.org
| jwilk wrote:
| 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)
| olvy0 wrote:
| 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.
| [deleted]
| jsd1982 wrote:
| 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 wrote:
| 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 wrote:
| Why not implement a program that reads from stdin, strips any
| ansi color, and writes to stdout?
| taftster wrote:
| 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.
| hnlmorg wrote:
| 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.
| aidenn0 wrote:
| Most programs disable color output when piped, so just piping
| to cat already accomplishes this.
| [deleted]
| adeon wrote:
| 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.
| fwlr wrote:
| 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.
| userbinator wrote:
| _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/
| bobbylarrybobby wrote:
| 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.
| drivingmenuts wrote:
| > 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.
| bobbylarrybobby wrote:
| 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.
| JdeBP wrote:
| 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.
| aidenn0 wrote:
| > 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.
| shakow wrote:
| 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.
| bombcar wrote:
| 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.
| rubicks wrote:
| Because no one deserves the onus of the opt-out, least of all
| the colorblind.
| lolinder wrote:
| 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.
| JdeBP wrote:
| Please make them respect TERM=dumb _first_ , then consider
| doing non-standard environment variables after that.
| sarthak-ag wrote:
| 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.
| bigdict wrote:
| Isn't the real problem that these escape codes mess up the
| parsing of the output?
| fiddlerwoaroof wrote:
| > 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.
| leni536 wrote:
| 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.
| mikro2nd wrote:
| And yellow on white is completely unreadable...
| arp242 wrote:
| > 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.
| lolinder wrote:
| Is there a good use case for applications explicitly
| setting a dark background? If you're playing games in your
| terminal I can see it, but I'm having a hard time imagining
| a good use case beyond that.
| arp242 wrote:
| Many TUIs do this, and some CLIs as well (e.g. npm).
| scythe wrote:
| 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.
| throw0101b wrote:
| > _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.
| lolinder wrote:
| 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.)
| charcircuit wrote:
| There are 256^3 colors.
| lolinder wrote:
| 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.
| bitwize wrote:
| Last time I used Slackware, entering 'vi' still invoked
| elvis, a sufficiently minimal vi clone.
|
| Vim was there too, under 'vim'.
| JdeBP wrote:
| 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.)
| arp242 wrote:
| > 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.
| pie_flavor wrote:
| 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.
| kps wrote:
| > 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.)
| sodapopcan wrote:
| 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.
| cratermoon wrote:
| > 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 wrote:
| 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.
| JdeBP wrote:
| 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.)
| pie_flavor wrote:
| 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.
| nucleardog wrote:
| 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.
| cratermoon wrote:
| > 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.
| rollcat wrote:
| 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 wrote:
| 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.
| rollcat wrote:
| 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.
| syngrog66 wrote:
| 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
| lolinder wrote:
| 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.
| geocar wrote:
| 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?
| linsomniac wrote:
| 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.
| geocar wrote:
| 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 wrote:
| 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.
| aib wrote:
| Try LESS='-X'
| jonhohle wrote:
| 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.
| awestroke wrote:
| Why not just change all colors to the same color (b/w) in your
| terminal emulator settings??
| hnlmorg wrote:
| 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.
| londons_explore wrote:
| 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?
| endgame wrote:
| 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.
| kps wrote:
| Yes, it would be better if colour were opt-in.
| rippercushions wrote:
| Where's the fun in that? Use NO_FOO=enable,disable to maximize
| ambiguity.
| serpix wrote:
| To increase confusion the variable name should contain the
| verb as well: NO_COLOR_DISABLED=enabled
| deathless wrote:
| [dead]
| treve wrote:
| 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 wrote:
| They also won't output stuff like progress bars, width-aware
| content, and may change other behavior. It would also annoying
| to pipe everything.
| zaptheimpaler wrote:
| 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.
| geocar wrote:
| > 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?
| pcthrowaway wrote:
| Is behaviour defined for programs with a `--color=always` flag
| set in combination with NO_COLOR? I'd assume `--color=always`
| takes precedence
| ksherlock wrote:
| 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.
| aigoochamna wrote:
| 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.
| olgeni wrote:
| Also, please don't barf random emojis on the terminal.
| epage wrote:
| 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 wrote:
| 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.
| PhilipRoman wrote:
| 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.
| arp242 wrote:
| 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).
| tpoacher wrote:
| 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...
| EdwardDiego wrote:
| My favourite dumb about colour application is Terraform. So many
| logs from GH Actions have useless ANSI escape sequences in them.
| erik_seaberg wrote:
| They seem to be using
| https://github.com/mitchellh/colorstring/blob/master/colorst...
| instead of isatty and curses and terminfo.
| EdwardDiego wrote:
| 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 :/
| usrbinbash wrote:
| > 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.
| ori_b wrote:
| > 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 wrote:
| > 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.
| ori_b wrote:
| 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....
| pessimizer wrote:
| > 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?
| andreareina wrote:
| 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 wrote:
| Sure, but that has a simple solution not even mentioned in
| this post: isatty(1)
| interfixus wrote:
| > _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.
| EdwardDiego wrote:
| And I tried NO_POINTLESS_SNARK=1, and yet here we both are.
| stefantalpalaru wrote:
| [dead]
| chroma wrote:
| 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 wrote:
| 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.
| esprehn wrote:
| Piping to cat won't work for an interactive tool though.
| comradesmith wrote:
| That's still up to the developer of the producer to implement
| ktpsns wrote:
| 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).
| DSMan195276 wrote:
| 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.
| kevin_thibedeau wrote:
| The isatty() check is obnoxious when you _do_ want to
| preserve the control chars and can 't force it on.
| franga2000 wrote:
| 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/
| doix wrote:
| 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.
| kps wrote:
| > 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 comment1 points out pipetty2 as a
| workaround, so I learned something useful today.
|
| 1 https://news.ycombinator.com/item?id=36102160
|
| 2 https://github.com/kilobyte/colorized-logs
| nerdponx wrote:
| 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?
| aidenn0 wrote:
| > 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.
| [deleted]
| n2d4 wrote:
| 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.
| bitwize wrote:
| > 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.
| JdeBP wrote:
| 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/79b1c0aab9834a09a5
| 9e15d47... . And yes, I implement that convention. "dumb"
| gets several mentions at https://jdebp.uk/Softwares/nosh/
| guide/commands/TerminalCapab... .
| akvadrako wrote:
| 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.
| JdeBP wrote:
| 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
| akvadrako wrote:
| 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.
| rice7th wrote:
| Yeah. If you don't like colors just diable them from the
| terminal.
| aumerle wrote:
| terminal emulators dont actually know this. Just think of
| executing something via ssh. In this case the primary
| foreground process is ssh.
| TheRealPomax wrote:
| 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 wrote:
| 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
| noitpmeder wrote:
| 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.
| chroma wrote:
| 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.
| Waterluvian wrote:
| 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.
| kps wrote:
| I want colour, in certain places, under my control. I don't
| want every random tool spewing confetti.
| cat_plus_plus wrote:
| 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?
| alpaca128 wrote:
| 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.
| cat_plus_plus wrote:
| 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.
| JdeBP wrote:
| 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.
| kps wrote:
| 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.
| [deleted]
| emmelaich wrote:
| You could copy an existing terminfo entry and remove the
| colour.
|
| Or use an existing one like _ansi-mono_
| geocar wrote:
| 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.
___________________________________________________________________
(page generated 2023-05-28 23:02 UTC)