7 ms·

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

by chroma 3y 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 3y 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 3y ago
  That’s still up to the developer of the producer to implement
- esprehn 3y ago
  Piping to cat won't work for an interactive tool though.
ktpsns 3y 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-from-output 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 3y 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 3y 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.
  - bitwize 3y 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? 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 3y ago
      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 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/man7/term.7 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 https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47710f355c5c0417a/source/TerminalCapabilities.cpp#L54 https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapabilities.xml https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .
- aidenn0 3y 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 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 3y ago
    [deleted]
- DSMan195276 3y 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.
  - kevin_thibedeau 3y ago
    The isatty() check is obnoxious when you do want to preserve the control chars and can't force it on.
    - doix 3y ago
      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 3y ago
        > That's a pretty niche case I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example. Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today. ¹ https://news.ycombinator.com/item?id=36102160 https://news.ycombinator.com/item?id=36102160 ² https://github.com/kilobyte/colorized-logs https://github.com/kilobyte/colorized-logs
    - franga2000 3y ago
      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/ https://bixense.com/clicolors/
rice7th 3y ago
Yeah. If you don't like colors just diable them from the terminal.
noitpmeder 3y 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 3y 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.
  - deleted 3y ago
    [deleted]
  - emmelaich 3y ago
    You could copy an existing terminfo entry and remove the colour. Or use an existing one like ansi-mono
  - kps 3y ago
    I want colour, in certain places, under my control. I don't want every random tool spewing confetti.
    - cat_plus_plus 3y ago
      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 3y ago
aumerle 3y ago
terminal emulators dont actually know this. Just think of executing something via ssh. In this case the primary foreground process is ssh.
TheRealPomax 3y 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 3y 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
geocar 3y 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.

by chroma 3y ago

jeroenhd 3y 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 3y ago
That’s still up to the developer of the producer to implement
esprehn 3y ago
Piping to cat won't work for an interactive tool though.

ktpsns 3y 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-from-output 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 3y 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 3y 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.
- bitwize 3y 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? 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 3y ago
    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 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/man7/term.7 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 https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47710f355c5c0417a/source/TerminalCapabilities.cpp#L54 https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapabilities.xml https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .
aidenn0 3y 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 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 3y ago
  [deleted]
DSMan195276 3y 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.
- kevin_thibedeau 3y ago
  The isatty() check is obnoxious when you do want to preserve the control chars and can't force it on.
  - doix 3y ago
    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 3y ago
      > That's a pretty niche case I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example. Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today. ¹ https://news.ycombinator.com/item?id=36102160 https://news.ycombinator.com/item?id=36102160 ² https://github.com/kilobyte/colorized-logs https://github.com/kilobyte/colorized-logs
  - franga2000 3y ago
    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/ https://bixense.com/clicolors/

rice7th 3y ago

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

noitpmeder 3y 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 3y 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.
- deleted 3y ago
  [deleted]
- emmelaich 3y ago
  You could copy an existing terminfo entry and remove the colour. Or use an existing one like ansi-mono
- kps 3y ago
  I want colour, in certain places, under my control. I don't want every random tool spewing confetti.
  - cat_plus_plus 3y ago
    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 3y ago

aumerle 3y ago

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

TheRealPomax 3y 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 3y 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

geocar 3y 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.