Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: