5 ms·

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

by 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... .
    - akvadrako 3y ago
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/

by ktpsns 3y ago

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... .
  - akvadrako 3y ago

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/