search

tokio-rs / tracing

Application level tracing for Rust.
https://tracing.rs
MIT License
5.48k stars 721 forks source link

Only colorize output when outputting to a TTY #1160

Open olix0r opened 3 years ago

olix0r commented 3 years ago

Feature Request

Motivation

Tracing's default output is colorized. But when a program is not connected to a terminal, for instance because its output is redirected to a file or another program like grep, this is undesirable because ANSI characters pollute the output.

Proposal

By default, tracing should only colorize output when its output stream is a TTY, similarly to how cargo works. When the output does not target a terminal, ANSI characters should be omitted.

It's probably desirable to support an environment variable, e.g. RUST_LOG_COLOR, that supports the values auto (default), never, and always (similar to cargo --color=...) so that users may override the automatic behavior as desired. This is especially useful when, for instance, redirecting the program's output like |& less so that colorized output can still be viewed in the pager.

jyn514 commented 3 years ago

It's probably desirable to support an environment variable, e.g. RUST_LOG_COLOR

Rustc does this with an environment variable, RUSTC_LOG_COLOR. I would prefer not to do this in tracing itself so the variable can be customized. Tracing could add an API setting the variable but at that point you may as well do it yourself in the application.

hawkw commented 3 years ago

An env variable can be implemented in user code with the current APIs in tracing-subscriber fmt::Layer::with_ansi and fmt::SubscriberBuilder::with_ansi. (Sidenote: maybe these should be renamed to with_colors or something in 0.3 for clarity?)

We could add support for a default env variable, though, if that's something people want --- but that part should be pretty easy to implement on top of the current API.

It's automatically detecting whether the output is a TTY that's significantly more challenging, especially with the current design of tracing_subscriber::fmt, where formatters are decoupled from IO. It's the IO writer that would know if the output supports ANSI colors, but the decision of whether or not to use ANSI colors is currently up to the formatter. We might have to redesign this a bit in order to support automatic detection.

coderedart commented 2 years ago

I would request that with_ansi be renamed to with_colors. Was confused as to how to disable colors and ansi was never the word I looked for in docs

hawkw commented 2 years ago

We could rename it to with_ansi_colors or something, in v0.4. I do think it's also important to be clear that the method specifically enables ANSI formatting escape codes, and not other forms of coloring, but I agree that it could be clearer if the name had the word "color" in it.

It does also control other formatting, though, such as bold and italic..

dpc commented 2 years ago

@zojw thank you for that mention with an example how to achieve the usually desired behavior.

stefnotch commented 7 months ago

It might be reasonable to use the supports-color crate for this. However, there is a trade-off that would have to be made