Currently colored doesn't have true windows support. In the mean time to allow some cross platform usability without risking dumping ANSI codes to the terminal the colored string can ignore coloring on the windows platform.

I've listed the details of each fix into its own commit message

Warnings were found by running

cargo clippy

and

cargo test

rust version 1.43.0

@kurtlawrence

Currently, it is stated everywhere that Windows support will be added in the future. I know how this is meant, you want to support older Windows consoles that do not have support for ANSI codes. However, it should be mentioned that recent Windows versions have full support for the coloring implementation of this crate, just to ensure that people are not running away frightened because they think that there is absolutely no coloring support on Windows.

https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/

Not sure if this is something getting incorrectly detected in this library, or a bug with the IDE, but colours set by this library don't display inside the IDE's integrated run output. This is possibly because it's internally redirected?

Repro:

use colored::*

fn main() {
  println!("{}", "hello world".blue())
}

In the IDE:

In Kitty:

Using v1.9.3.

I'm not sure how to debug this. I'm on Windows 10 using the command prompt. When I build my app from source, colored works as expected. But if I cargo install my program from crates.io (from the same source), I get output like this:

 Hello

term_painter works as expected from either source or cargo install. Running from cargo install for Linux and Mac work fine. Any ideas why this would be happening?

As it can be seen here, when combining styling and color in the same print, both color and style are reset when one of them stop, instead of returning to the color.

It would be great to have a static API which would enable/disable coloring. It would help for a finer control.

Example 1:

fn log_something(msg: String) {
    colored::force_colors(Some(ApplyColors::Never));  // never color
    log_with_colors_in_file(msg);                     // no colors applied
    colored::force_colors(Some(ApplyColors::Always)); // always color when asked
    log_with_colors_in_stdout(msg);                   // colors applied
    colored::force_colors(None);
    // back to default behavior
}

It could be with a color token (Example 2):

fn log_something(msg: String) {
    let token = colored::force_colors_scoped(Some(ApplyColors::Never));  // never color
    log_with_colors_in_file(msg);                     // no colors applied
    // first token goes out of scope, restoring default behavior
    // second token is emited
    let token = colored::force_colors_scoped(Some(ApplyColors::Always)); // always color when asked
    log_with_colors_in_stdout(msg);                   // colors applied
    // back to default behavior because second token goes out of scope
}

Via popular demand, the user should be able to force turning ON or OFF colored via an environment variable.

I consider using RUST_NOCOLOR and RUST_FORCECOLOR, but I would like to have the opinion of other implementers on the matter and see if we can coordinate a little.

This is the tracking issue.

I hope this example will make clear what I mean. Currently this test fails but is there any way to make it work?

        use colored::Colorize;
        let a = "something";
        let b = a.red().to_string();
        let c = a.clear().to_string();
        assert_eq!(a, c);

I used your crate in a project recently, and wanted to know how it worked.

Specifically, I wanted to understand how, by just adding

use colored::*

all of my strings suddenly got these color methods attached to them. Curious what the mechanism is that does this magic ✨

I would like it if there was a way to convert, say Color::Red to Color::BrightRed and back again with a method, maybe by splitting out the bright colours from Color into BrightColor. To convert, methods such as .bright() on Color and .normal() on BrightColor could be added.

If I want color output on stderr or stdout, I get colors. If I have colored stdout and redirect stderr to /dev/null, I still get color on stdout. If I have colored stderr and redirect stdout to /dev/null, I no longer get color on stderr. Is this expected behavior?

I ran into this issue when using simple_logger 4.0.0, but the problem appears to lie with colored (see here: https://docs.rs/colored/latest/src/colored/control.rs.html#108). The version of colored used was 2.0.0 and this was seen on macOS. Here is the original ticket I made in simple_logger: https://github.com/borntyping/rust-simple_logger/issues/71

Im trying to build a little app for fun with https://chat.openai.com/chat but it keeps telling me to use your lib to create CenteredString and PaddedStrings to format strings for the output of the app

the ia said:

 apologize for the confusion. The pad_to_width and center methods are not actually methods of the String or ColoredString types. They are methods of the PaddedString and CenteredString types, respectively, which are both subtypes of the ColoredString type.

To use the pad_to_width and center methods, you will need to call them on a PaddedString or CenteredString value, respectively. You can create a PaddedString or CenteredString value by calling the pad_to_width or center method on a ColoredString value, respectively.

Here is how you can modify the code to create a box around the summary information with both horizontal and vertical lines, using the pad_to_width and center methods on PaddedString and CenteredString values:

and

I am not actually using the colored crate in my current environment, as I am a text-based AI trained to assist with answering questions and providing information. I do not have the ability to run code or use external libraries.

However, the colored crate is actively maintained and the latest version, as of September 2021, is 2.0.3. You can check the latest version of the colored crate by visiting its page on crates.io:

https://crates.io/crates/colored

There never was a 2.0.3 version of Colored right ?

Problem

Currently the from_str function supports parsing color names to Color enum based on the names. But this function does not parse TrueColor.

https://github.com/mackwic/colored/blob/11ffd20e7b5d1b48e4de7bb78ced26131ae5e114/src/color.rs#L88

Expectation

Given a string like rgb(<u8>,<u8>,<u8>), from_str should support parsing it to a Color::TrueColor instance.

Suggestion

In a project of mine, I've used a regex check to determine if the string matches the specific pattern and converts it to Color::TrueColor. A refined version of this could be added in the crate to be supported out-of-the-box.

let true_color = Regex::new(r"(?x)^
    (?:bg:)?
    rgb\(
        (?P<red>\d{1,3}),\s?
        (?P<green>\d{1,3}),\s?
        (?P<blue>\d{1,3})
    \)
$").unwrap();

let mut color: Option<Color> = None;
if let Some(caps) = true_color.captures(style) { // RGB colors
    let channels: Vec<u8> = vec!["red", "green", "blue"]
        .into_iter()
        .map(|x| caps[x].parse().expect("Must be int between 0 and 255."))
        .collect();
    color = Some(Color::TrueColor { r: channels[0], g: channels[1], b: channels[2] });
}

atty is unmaintained and has a potential unaligned read. See https://github.com/rustsec/advisory-db/blob/main/crates/atty/RUSTSEC-2021-0145.md.

is-terminal is a replacement based on atty, with the soundness issue fixed and an (IMO) nicer to use API, mirroring what's available in the std lib on nightly with std::io::IsTerminal.

Added a macro to print colored output directly to the terminal.

Examples

println_color!(blue, bold, "This will be {} and {}!", "blue", "bold");

// is equivalent to:

println!("{}", format!("This will be {} and {}!", "blue", "bold").blue().bold());

// inner colorization will be applied on top
println_color!(magenta, "Most of this is magenta, but {} is red", "this".red());