#no-color #terminal #tty #color

color-nope

Support for standard options to disable colors in the terminal

4 releases (breaking)

0.4.0 Oct 30, 2022
0.3.0 Oct 29, 2022
0.2.0 Oct 29, 2022
0.1.0 Oct 29, 2022

#713 in Command-line interface

MIT license

9KB
91 lines

Color nope

GitHub Workflow Status GitHub Crates.io docs.rs

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.

Why

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:

  1. Support for NO_COLOR.

    This seems like a reasonable standard.

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

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

Examples

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}");

Dependencies

~225KB