While this crate follows https://bixense.com/clicolors/, several crates in the ecosystem (for example tracing) follow another convention of forcing tools not to print coloured output: https://no-color.org/
I wonder if it wouldn't be feasible to support both conventions simultaneously in this crate. The unknown question is which convention should be prioritized. Personally, I think it doesn't matter and would probably check NO_COLOR after CLICOLOR.
Relevant code, as far as I see, is only this chunk:
|
fn default_colors_enabled(out: &Term) -> bool { |
|
(out.features().colors_supported() |
|
&& &env::var("CLICOLOR").unwrap_or_else(|_| "1".into()) != "0") |
|
|| &env::var("CLICOLOR_FORCE").unwrap_or_else(|_| "0".into()) != "0" |
|
} |
While this crate follows https://bixense.com/clicolors/, several crates in the ecosystem (for example
tracing) follow another convention of forcing tools not to print coloured output: https://no-color.org/I wonder if it wouldn't be feasible to support both conventions simultaneously in this crate. The unknown question is which convention should be prioritized. Personally, I think it doesn't matter and would probably check
NO_COLORafterCLICOLOR.Relevant code, as far as I see, is only this chunk:
console/src/utils.rs
Lines 19 to 23 in de2f15a