http://bixense.com/clicolors/
Looks like this is already supported by more software; rather than an n+1 standard (https://xkcd.com/927/), why not use this one instead?
Looks like this is already supported by more software; rather than an n+1 standard (https://xkcd.com/927/), why not use this one instead?
One other potential issue with this (an issue that also applies to GNU make's MAKE_TERMOUT and MAKE_TERMERR environment variables, documented at https://www.gnu.org/software/make/manual/make.html#Terminal-...): what happens if someone sets CLICOLOR_FORCE or MAKE_TERMOUT to indicate that output will (eventually) go to a terminal for output, but then some portion of the build system actually does want to redirect output to a file or pipe that won't eventually get printed to a terminal? Does that part of the build system then need to explicitly unset CLICOLOR_FORCE and MAKE_TERMOUT and any other variable the program might potentially respect, to make sure it won't include color in its output? That seems likely to produce breakage.
Consider if grep respected CLICOLOR_FORCE or MAKE_TERMOUT. What would happen if a build system set one of those, and then somewhere deep in the build system (or even in a shell script called from the build system), someone ran grep in a pipeline, along with various other text processing commands? If grep respected those environment variables, then that pipeline would break.
I do like the idea of having a standard way to tell a program "no, really, your output will wind up on the terminal, please print in color even though it doesn't look like a TTY". However, I don't think it makes sense to do so without a solution for this problem. Not showing color output is an annoyance; breaking a build by printing color escape sequences to a pipe would be far worse.
(This is also part of why programs like grep are removing environment variables like GREP_OPTIONS: they break scripts.)
Yes, it should be the responsibility of the build system to control the environment variables set during the build.
What would happen if a build system set one of those, and then somewhere deep in the build system (or even in a shell script called from the build system), someone ran grep in a pipeline
The person adding the 'grep' would need to be aware of whether the build system is using color output or not.
This is also part of why programs like grep are removing environment variables like GREP_OPTIONS: they break scripts.
This seems unfortunate; scripts could just unset GREP_OPTIONS if they care.
grep is portable, and much older than GREP_OPTIONS. A script shouldn't be expected to fix any random non-standard idiosyncrasy of the local version of grep.
It would be great if grep could figure out whether its parent process is an interactive shell or a script, but there doesn't seem to be a reliable way to do that.
programs like make could collect output using a pty rather than a pipe or temp file
This seems brilliant. The pipe mechanism is too dumb to differentiate between these cases - Unix needs a smarter pipe, and pty could be it. Maybe there could be another character in the shell for a pipe that's really a pty like '_', or a digraph like '|p'.
I think that just having the CLICOLOR option would be reasonable, for enabling or disabling color to a TTY, but CLICOLOR_FORCE is more problematic.
Yeah, I'd agree with that.