1# env_logger
2
3[![crates.io](https://img.shields.io/crates/v/env_logger.svg)](https://crates.io/crates/env_logger)
4[![Documentation](https://docs.rs/env_logger/badge.svg)](https://docs.rs/env_logger)
5
6Implements a logger that can be configured via environment variables.
7
8## Usage
9
10### In libraries
11
12`env_logger` makes sense when used in executables (binary projects). Libraries should use the [`log`](https://docs.rs/log) crate instead.
13
14### In executables
15
16It must be added along with `log` to the project dependencies:
17
18```console
19$ cargo add log env_logger
20```
21
22`env_logger` must be initialized as early as possible in the project. After it's initialized, you can use the `log` macros to do actual logging.
23
24```rust
25use log::info;
26
27fn main() {
28    env_logger::init();
29
30    info!("starting up");
31
32    // ...
33}
34```
35
36Then when running the executable, specify a value for the **`RUST_LOG`**
37environment variable that corresponds with the log messages you want to show.
38
39```bash
40$ RUST_LOG=info ./main
41[2018-11-03T06:09:06Z INFO  default] starting up
42```
43
44The letter case is not significant for the logging level names; e.g., `debug`,
45`DEBUG`, and `dEbuG` all represent the same logging level. Therefore, the
46previous example could also have been written this way, specifying the log
47level as `INFO` rather than as `info`:
48
49```bash
50$ RUST_LOG=INFO ./main
51[2018-11-03T06:09:06Z INFO  default] starting up
52```
53
54So which form should you use? For consistency, our convention is to use lower
55case names. Where our docs do use other forms, they do so in the context of
56specific examples, so you won't be surprised if you see similar usage in the
57wild.
58
59The log levels that may be specified correspond to the [`log::Level`][level-enum]
60enum from the `log` crate. They are:
61
62   * `error`
63   * `warn`
64   * `info`
65   * `debug`
66   * `trace`
67
68[level-enum]:  https://docs.rs/log/latest/log/enum.Level.html  "log::Level (docs.rs)"
69
70There is also a pseudo logging level, `off`, which may be specified to disable
71all logging for a given module or for the entire application. As with the
72logging levels, the letter case is not significant.
73
74`env_logger` can be configured in other ways besides an environment variable. See [the examples](https://github.com/rust-cli/env_logger/tree/main/examples) for more approaches.
75
76### In tests
77
78Tests can use the `env_logger` crate to see log messages generated during that test:
79
80```toml
81[dependencies]
82log = "0.4.0"
83
84[dev-dependencies]
85env_logger = "0.10.0"
86```
87
88```rust
89fn add_one(num: i32) -> i32 {
90    info!("add_one called with {}", num);
91    num + 1
92}
93
94#[cfg(test)]
95mod tests {
96    use super::*;
97    use log::info;
98
99    fn init() {
100        let _ = env_logger::builder().is_test(true).try_init();
101    }
102
103    #[test]
104    fn it_adds_one() {
105        init();
106
107        info!("can log from the test too");
108        assert_eq!(3, add_one(2));
109    }
110
111    #[test]
112    fn it_handles_negative_numbers() {
113        init();
114
115        info!("logging from another test");
116        assert_eq!(-7, add_one(-8));
117    }
118}
119```
120
121Assuming the module under test is called `my_lib`, running the tests with the
122`RUST_LOG` filtering to info messages from this module looks like:
123
124```bash
125$ RUST_LOG=my_lib=info cargo test
126     Running target/debug/my_lib-...
127
128running 2 tests
129[INFO my_lib::tests] logging from another test
130[INFO my_lib] add_one called with -8
131test tests::it_handles_negative_numbers ... ok
132[INFO my_lib::tests] can log from the test too
133[INFO my_lib] add_one called with 2
134test tests::it_adds_one ... ok
135
136test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured
137```
138
139Note that `env_logger::try_init()` needs to be called in each test in which you
140want to enable logging. Additionally, the default behavior of tests to
141run in parallel means that logging output may be interleaved with test output.
142Either run tests in a single thread by specifying `RUST_TEST_THREADS=1` or by
143running one test by specifying its name as an argument to the test binaries as
144directed by the `cargo test` help docs:
145
146```bash
147$ RUST_LOG=my_lib=info cargo test it_adds_one
148     Running target/debug/my_lib-...
149
150running 1 test
151[INFO my_lib::tests] can log from the test too
152[INFO my_lib] add_one called with 2
153test tests::it_adds_one ... ok
154
155test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
156```
157
158## Configuring log target
159
160By default, `env_logger` logs to stderr. If you want to log to stdout instead,
161you can use the `Builder` to change the log target:
162
163```rust
164use std::env;
165use env_logger::{Builder, Target};
166
167let mut builder = Builder::from_default_env();
168builder.target(Target::Stdout);
169
170builder.init();
171```
172
173## Stability of the default format
174
175The default format won't optimise for long-term stability, and explicitly makes no guarantees about the stability of its output across major, minor or patch version bumps during `0.x`.
176
177If you want to capture or interpret the output of `env_logger` programmatically then you should use a custom format.
178