Crates.io | color-nope |
lib.rs | color-nope |
version | 0.4.0 |
source | src |
created_at | 2022-10-29 14:48:56.201525 |
updated_at | 2022-10-30 15:49:44.857762 |
description | Support for standard options to disable colors in the terminal |
homepage | https://github.com/ThomWright/color-nope |
repository | https://github.com/ThomWright/color-nope |
max_upload_size | |
id | 701052 |
size | 12,117 |
Color? Nope. Nope nope nope.
Support for standard options to disable colors in the terminal.
An implementation of the NO_COLOR
standard, following the Command Line Interface Guidelines.
Different libraries do this their own way, often accessing global state (e.g. env vars), and sometimes assuming the output is always going to stdout.
What I wanted:
Support for NO_COLOR
.
This seems like a reasonable standard.
The ability to disable colors for stdout and stderr independently.
Sometimes one might be connected to a tty, and the other piped to a file (for example).
To keep access to global state (e.g. env vars) exclusively inside my application (not in libraries).
I have a strong belief that for the most part, libraries shouldn't touch global state. I, as the application developer, should be able to decide which environment variables I want to use and should be able to pass those to libraries.
In this case, if I use two libraries to control color where one of them uses NO_COLOR
and the other uses CLICOLOR
then I'm pretty stuck unless I can take control back.
Using the from_env()
convenience function:
use color_nope::{ColorNope, Stream};
let enable_color = ColorNope::from_env().enable_color_for(Stream::Stdout);
println!("{enable_color}");
Or by passing in your own values:
use color_nope::{ColorNope, Stream, Force};
let enable_color = ColorNope::new(
std::env::var_os("TERM"),
std::env::var_os("NO_COLOR"),
if std::env::args_os().any(|a| a == "--no-color") {
Some(Force::Off)
} else {
None
},
)
.enable_color_for(Stream::Stdout);
println!("{enable_color}");