4 ms·

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 patchi

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.

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.