4 ms·

http://bixense.com/clicolors/ http://bixense.com/clicolors/ Looks like this is already supported by more software; rather than an n+1 standard (https://xkcd.co

by lambda 9y ago

http://bixense.com/clicolors/ http://bixense.com/clicolors/ Looks like this is already supported by more software; rather than an n+1 standard (https://xkcd.com/927/ https://xkcd.com/927/), why not use this one instead?

JoshTriplett 9y ago
Quoting a comment I made at https://github.com/rust-lang/rust/pull/27867#issuecomment-221964712 https://github.com/rust-lang/rust/pull/27867#issuecomment-22... about that: 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-Output 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.)
- racer-v 9y ago
  I like your solution further down in the Rust pull request: 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'.
- racer-v 9y ago
  Does that part of the build system then need to explicitly unset CLICOLOR_FORCE and MAKE_TERMOUT 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.
  - JoshTriplett 9y ago
    > 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.
    - racer-v 9y ago
      Fair enough; since GREP_OPTIONS seems only useful for interactive sessions, perhaps non-interactive shells should purge it from the environment (e.g. with BASH_ENV). 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.
- lambda 9y ago
  Yeah, that's a pretty reasonable concern. Environment variables can be problematic because they are usually inherited when spawning processes, and many build systems rely on this for things like passing through compiler flags. 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.
  - JoshTriplett 9y ago
    > 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.

by lambda 9y ago

JoshTriplett 9y ago

Quoting a comment I made at https://github.com/rust-lang/rust/pull/27867#issuecomment-221964712 https://github.com/rust-lang/rust/pull/27867#issuecomment-22... about that: 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-Output 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.)

racer-v 9y ago
I like your solution further down in the Rust pull request: 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'.
racer-v 9y ago
Does that part of the build system then need to explicitly unset CLICOLOR_FORCE and MAKE_TERMOUT 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.
- JoshTriplett 9y ago
  > 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.
  - racer-v 9y ago
    Fair enough; since GREP_OPTIONS seems only useful for interactive sessions, perhaps non-interactive shells should purge it from the environment (e.g. with BASH_ENV). 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.
lambda 9y ago
Yeah, that's a pretty reasonable concern. Environment variables can be problematic because they are usually inherited when spawning processes, and many build systems rely on this for things like passing through compiler flags. 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.
- JoshTriplett 9y ago
  > 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.