[afranchuk]

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]

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]

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]

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]

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 :)