4 ms·

> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. The main use case for this is that t

by lhorie 5y ago

> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely. The main use case for this is that there are tools that use ANSI color libraries and don't handle non-colorization in non-TTY contexts. So what ends up happening is a user of said tool pipes its output to a log file and since ANSI escape codes are in-band, the log file becomes an unreadable mess. NO_COLOR provides a way for the library to give control over colorization to the user, even if the tool consuming the library hard codes colorization logic.

afranchuk 5y ago
I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.
- noitpmeder 5y ago
  It's pretty bad for usability for all downstream tooling. Grepping log files is immediately worse... Ingestion into pipelines (like ELK) is considerably degraded... I can imagine almost every other tool would be similarly degraded. I think it's fine if the logs are going straight to stdout/stderr in a console. Any other destination (piped output, logfile) should default to no color.
  - mcswell 5y ago
    Grepping anything that has ANSI color codes would, I would think, be awful. Same for lots of other tools: sed, awk etc. So agreed, piped output should default to no color, and not just for the log file situation.
- lilyball 5y ago
  A lot of display tools support them (though you might find issues with CI systems that show the lot in a web page) but a lot of processing tools don’t. For example, you might have difficulty using grep on your log file if there are escape codes sprinkled through it.
- lhorie 5y ago
  Unfortunately, NO_COLOR is only the tip of the iceberg. Yes you can clean up ANSI escape codes upon human consumption in some cases, but not always. E.g. often these log files are meant to be displayed in web UIs (e.g. Jenkins). Things get really chaotic when tools call other tools via child processes. Then, you might have one tool forcing colors via the FORCE_COLOR ad hoc standard to force colors through non-TTY pipes, but the user of the tool wants to, again, pipe the output to a log for display on the web... Don't even get me started on TrueColor :)
alex_smart 5y ago
This does not make any sense at all. The intent is to fix programs that don't handle non-colorization in non-TTY context, and the solution is to do so by patching them by responding to an environment variable or command-line option to explicitly request no colors. Why not just fix them to handle non-colorization in non-TTY context correctly? This is also in opposition to the motivation explicitly laid out in the website itself. >An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, some users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all. Clearly, the motivation laid out here is in fact to provide a standard mechanism to disable the colors seen by the user on the terminal. Not to disable coloring when output is being redirected.
- lhorie 5y ago
  > Why not just fix them to handle non-colorization in non-TTY context correctly "Why not just" = lack of experience in the domain From my experience, the usual reasons are: unwillingness from tool author to accept PRs, tool is unmaintained/abandoned, tool forces color across a non-TTY in child processes calling other tools inside of itself, "ain't nobody got time to patch hundreds of random tools that are downstream of some popular colorization library", etc. Your reading of the motivation is naive. Piping is something users do. Whether a single user never wants colors or only sometimes is kinda irrelevant to the point that the feature is desired by users at all. As I mentioned in my other comment, colorization wonkiness doesn't end with NO_COLOR; there's also FORCE_COLOR, --color/--colors/--no-color/--no-colors, TERM, CI, glue tools calling other tools with one or more of those flags, users who sometimes want colors but sometimes not, regardless of TTY-ness, configurable terminal colors, user-facing non-TTY pipes, fragmented TrueColor support, etc. There's probably enough wonkiness in the domain of terminal colors in the wild to write one of those "falsehoods programmers believe about" articles.

by lhorie 5y ago

afranchuk 5y ago

I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.

noitpmeder 5y ago
It's pretty bad for usability for all downstream tooling. Grepping log files is immediately worse... Ingestion into pipelines (like ELK) is considerably degraded... I can imagine almost every other tool would be similarly degraded. I think it's fine if the logs are going straight to stdout/stderr in a console. Any other destination (piped output, logfile) should default to no color.
- mcswell 5y ago
  Grepping anything that has ANSI color codes would, I would think, be awful. Same for lots of other tools: sed, awk etc. So agreed, piped output should default to no color, and not just for the log file situation.
lilyball 5y ago
A lot of display tools support them (though you might find issues with CI systems that show the lot in a web page) but a lot of processing tools don’t. For example, you might have difficulty using grep on your log file if there are escape codes sprinkled through it.
lhorie 5y ago
Unfortunately, NO_COLOR is only the tip of the iceberg. Yes you can clean up ANSI escape codes upon human consumption in some cases, but not always. E.g. often these log files are meant to be displayed in web UIs (e.g. Jenkins). Things get really chaotic when tools call other tools via child processes. Then, you might have one tool forcing colors via the FORCE_COLOR ad hoc standard to force colors through non-TTY pipes, but the user of the tool wants to, again, pipe the output to a log for display on the web... Don't even get me started on TrueColor :)

alex_smart 5y ago

This does not make any sense at all. The intent is to fix programs that don't handle non-colorization in non-TTY context, and the solution is to do so by patching them by responding to an environment variable or command-line option to explicitly request no colors. Why not just fix them to handle non-colorization in non-TTY context correctly? This is also in opposition to the motivation explicitly laid out in the website itself. >An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, some users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all. Clearly, the motivation laid out here is in fact to provide a standard mechanism to disable the colors seen by the user on the terminal. Not to disable coloring when output is being redirected.

lhorie 5y ago
> Why not just fix them to handle non-colorization in non-TTY context correctly "Why not just" = lack of experience in the domain From my experience, the usual reasons are: unwillingness from tool author to accept PRs, tool is unmaintained/abandoned, tool forces color across a non-TTY in child processes calling other tools inside of itself, "ain't nobody got time to patch hundreds of random tools that are downstream of some popular colorization library", etc. Your reading of the motivation is naive. Piping is something users do. Whether a single user never wants colors or only sometimes is kinda irrelevant to the point that the feature is desired by users at all. As I mentioned in my other comment, colorization wonkiness doesn't end with NO_COLOR; there's also FORCE_COLOR, --color/--colors/--no-color/--no-colors, TERM, CI, glue tools calling other tools with one or more of those flags, users who sometimes want colors but sometimes not, regardless of TTY-ness, configurable terminal colors, user-facing non-TTY pipes, fragmented TrueColor support, etc. There's probably enough wonkiness in the domain of terminal colors in the wild to write one of those "falsehoods programmers believe about" articles.