The library works fine when I am using print! or println!. But when writing to stdout, like:

let mut stdout = stdout();
let s = "Hello\n".truecolor(200, 50, 50);
stdout.write(s.as_bytes());
stdout.flush();

I see only regular black-and-white text. How do I get the library to work with stdout?

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.

like #4 but with feature flags. I am not fan of the Force color by feature flag but I understand this could eventually be needed by a consumer library.

Disable color by feature flag is a must need.

Building the current head gives:

error[E0658]: use of unstable library feature 'copied' (see issue #57126)
   --> /home/jlevon/.cargo/registry/src/github.com-1ecc6299db9ec823/colored-1.9.2/src/lib.rs:311:31
    |
311 |         self.fgcolor.as_ref().copied()
    |                               ^^^^^^

error[E0658]: use of unstable library feature 'copied' (see issue #57126)
   --> /home/jlevon/.cargo/registry/src/github.com-1ecc6299db9ec823/colored-1.9.2/src/lib.rs:324:31
    |
324 |         self.bgcolor.as_ref().copied()
    |                               ^^^^^^

If it's intentional that this crate now requires unstable library feature, should the README be updated with the minimal rust version?

Please make it conditional.

I'd expected to be able to push a coloured string into another, but it loses the colour:

fn main() {
    let mut s = String::with_capacity(5);
    let msg = "blue";
    s.push_str(&msg.blue());

    println!("{}", msg.blue()); // works
    println!("{}", s); // no colour
}

Is this supported?

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:

 �[90mHello�[0m

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?

Is there any way we can color characters and not just strings?

 println!("{} {} {} {}!",                                                    
             "it".green(),
             "works".blue().bold(),
             "great".bold().yellow(),
             "great".yellow()
             );

TERM is xterm-256color but linux and xterm have the same effect.
tried in xfce4-terminal 0.8.6-1 on ArchLinux

oh crap i just realized why!

Nevermind! :)
I set it to yellow myself now, but the tooltip is interesting, why would it expect it to be somehow both?

Implements:

"hello".palette(23); // 23nth colour of palette
"hello".true_colour(23, 45,  23); // true colour code
"hello".hex_colour("#232332"); // hex colour code

It is showing numbers rather than color. in this case blue

Though i have added control::set_virtual_terminal(true); in my source file.

ShouldColorize::from_env() completly ignores wether it runs in an environment that is capable of displaying colors or not and always generates color control codes.

Steps to reproduce:

1. Write a test program that uses colored.
2. Start the program with TERM=dumb ./my-test-program

Expected behavior:

3. The output in uncolored.

Observed behavior:

3. The output is colored.

The README contains the lines

"purple and magenta are the same".purple().magenta();
"you can specify color by string".color("blue").on_color("red");
"and so are normal and clear".normal().clear();

The first and third were originally adjacent. The insertion of the second in the middle broke the continuity between them. Maybe transpose the second and third line?

You already have this as a TODO, but I'm submitting it as an issue so I can watch for it to be closed. :)

Hello!
I'm using this code "\x1b[90m" to create a dark grey color in the terminal.
How can I make such color using this library?

I've checked almost everything, but it just doesn't work.

extern crate colored;

use colored::*;

fn main() {
    println!("abc123".green());
}

For a start 0xdeadbeef.red() would be such an ergonomic gain I'd cry from happiness :)

Readme states the following:

You can use have even finer control by using the colored::control::should_colorize methods.

However there is no such thing I think, one has to use:

colored::control::set_override(...);

We should be able to make our own colors, and use them wherever we want.
Example:

use colored::*;

fn main() {
let greyish = make_color!(100, 100, 100); //In this, 'make_color!' macro is the syntax to make a new color, which we can use anywhere by:
println!("{}", "Hello".greyish()); // So that we don't have to keep typing 'truecolor(....)' and so on...
}

Felt it would be nice..

I'm struggling to get colors working on Mac OS (Catalina) when running through Terminal. I can get other CLIs with colors to display (e.g. ls, git, etc.), but colors coming from the colored package don't show up.

If I run the same thing through VS Code's terminal, the colors do show up.

Are you aware of any settings I need play with to get this working or limitations of the default terminal? I have tried these with no luck:

• CLICOLOR
• CLICOLOR_FORCE
• NO_COLOR

I'm using the following:

[dependencies]
colored = "2.0.0"

Thanks and I'm really enjoying the crate!

The colours are displayed as code in the standard command prompt on Windows 10.

What it looks like:

What it should look like (using Cmder):

Code used

I know the cmd supports colours, since Cargo displays colours just fine.

Why not implement this?

impl<T: ToString> Colorize for T {
    fn foo(&self) -> ColoredString { Colorize::foo(&self.to_string()) }
}

Note that this will also automatically cover all types that implement Display due to ToString's blanket implementation.

This way, you can, e.g.

println!("{} + {} = {}", 1.blue(), 2.red(), 3.green());

(and many other types)

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.

I use colored in a small tool that generates my shell prompt (rusty-prompt).
After updating colored from 1.8.0 to 1.9.0 I noticed that my shell prompt was not colored anymore, neither in bash nor in zsh. I then compiled rusty-prompt against all commits between 1.8.0 and 1.9.0 of colored and figured out that this commit broke the coloring for me: 4af2de0 .
The reason seems to be that colored now wrongly detects my terminal as TTY.

When using the colored crate together with the pager crate it doesn't produce colored output.

Here's a repo that reproduces this behavior: https://github.com/soenkehahn/colored-bug
In there, cargo run should produce the word foo in red to stdout, but it's not red.

This used to work in version 1.8.0. The commit where this stopped working seems to be this one: 4af2de0

Replace extern crate colored; // not needed in Rust 2018 by 2018+
New users could believe that the 2018 version exclusively don't requires it

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/

When I run a cargo test after cloning this repository, I get this:

   Compiling colored v1.5.2 (file:///...../colored)
error[E0432]: unresolved import `rspec::context::*`
  --> src/control.rs:95:9
   |
95 |     use rspec::context::*;
   |         ^^^^^^^^^^^^^^^^^^ Could not find `context` in `rspec`

error[E0433]: failed to resolve. Could not find `formatter` in `rspec`
   --> src/control.rs:105:29
    |
105 |         let mut formatter = rspec::formatter::Simple::new(stdout);
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Could not find `formatter` in `rspec`

error[E0425]: cannot find function `describe` in this scope
   --> src/control.rs:106:26
    |
106 |         let mut runner = describe("ShouldColorize", |ctx| {
    |                          ^^^^^^^^ not found in this scope
    |
help: possible candidates are found in other modules, you can import them into scope
    |     fn clicolor_behavior() use rspec::block::describe;
    |     fn clicolor_behavior() use rspec::describe;

error: aborting due to previous error(s)

error: Could not compile `colored`.
Build failed, waiting for other jobs to finish...
error: build failed

Travis build also fails due to this.

I might take a look at it if I find the time, but don't take this as a promise 🙂

Hello, I've got problem with coloring after saving program output to variable, thats my code

use colored::*;

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

and then it's wrapped using bash script

output=$(program)
echo -e "${output}"

and it prints out hello world without colors. ansi_term crate works.

the hidden() call actually maps to inverse image/reversed, e.g., 0x1b[7m

Awesome api btw!

It would be helpful if you could mention the MSRV for this crate and also enforce that in Travis. Thanks :)

I'd like to request a new release of the package which would include the following changes: 3328890 & 49584e5.

Thanks!

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:

Please close this issue asap you read. Really great library.

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

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
}

Hi! I'm using set_override to disable color output for my tests at their start and use unset_override at their end. Time to time tests could fail. The reason is I'm still getting colored output. Could this issue be related to Ordering::Relaxed memory ordering used in override methods?

See title. I don't know if this is already possible using the current possibilities of const fn, but setting a color on a constant string is definitely something I would expect to be possible.

Winconsole maintainer has been MIA for almost a year.

The method is .reverse(), while the object is Styles::Reversed. All of the other styles, including dimmed, have the same spelling in both cases. Moreover, the documentation does not mention the difference, as it only mentions reversed. This makes it very hard to discover the .reverse() method.

I would recommend adding the .reversed() method which does the same thing as .reverse(), or at least clarifying the situation in the documentation.

I can read the style on a ColoredString and analyze it, but there's no way to easily copy that style to another string, or build up a style dynamically before setting it.

I'd like to see a 'set_style' function on the Colorize trait. It would be even nicer if the 'add' method on Style were made public so I can create my own styles before calling set_style.

For example I have a *.conf that saves a color value for the UI, it seems like it would be easier if it was possible to be able to do .color("green") or .color(config.ui_color)

like that but in terminal

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 ✨

Hi - I was about to fix the conditional dependency on winconsole, but I see it's already fixed. Could you update the crates.io version with at least that fix?

Currently, colored makes no check on whether the output is a tty. This goes at odds with the specs: https://bixense.com/clicolors/

CLICOLOR != 0 ANSI colors are supported and should be used when the program isn’t piped.

I propose to implement coloring exactly the way the specs suggest to do it (example in python):

def has_colors():
    if ((os.getenv("CLICOLOR", "1") != "0" and sys.stdout.isatty()) or
        os.getenv("CLICOLOR_FORCE", "0") != "0"):
        return True
    else:
        return False

I'll try to provide a PR later as well, if there are no objections to the plan.

Hi, I have a strange issue. First of those two ways does not work, the second does (paints text with green as expected).

use colored::{Colorize, Color};

fn main() {
    let mut buffer = String::with_capacity(400);
    buffer.push_str(&*"supposed to be green text".color(Color::BrightGreen));                            // does not work
    buffer.push_str(format!("{}", "supposed to be green text".color(Color::BrightGreen)).as_str());      // works
    println!("{}", buffer);
}

Sometime we need to colorize some numbers, for example:

println!("balance:{}", 100);

It will be better if we can write something like this:

100.red();
100.5.yellow()

Hi I would like to know if I am able to make something like vim out of this crate?