Because DisplayFrame uses colored, the output of display-formatting a value is not consistently colored, even if you've called Frame::display(true).
To reproduce, you can start a session with e.g. probe-rs run and tee the output into a file.
In some cases, this is desired. However, if one is writing logs to a file and you want logs, the format in those logs now suddenly depends on how you've started the program.
The use-case is something like:
fn main() {
log::info!("Started main process");
write_logs_for_remote_things();
}
fn write_logs_for_remote_things() {
loop {
let log_msg = writeln!("{}", decoded_defmt_frame.display(true));
File::open("file").write_all(log_msg.as_bytes()).ok()?;
log::info!("Logged a message to the file");
}
}In this case, it's rather unexpected that the value of log_msg depends on the way the binary that is running this logging operation was started (i.e. if the stdout of the process is not a terminal, log_msg is not actually colored, as the colored crate checks this before actually coloring the output text).
Because
DisplayFrameusescolored, the output of display-formatting a value is not consistently colored, even if you've calledFrame::display(true).To reproduce, you can start a session with e.g.
probe-rs runandteethe output into a file.In some cases, this is desired. However, if one is writing logs to a file and you want logs, the format in those logs now suddenly depends on how you've started the program.
The use-case is something like:
In this case, it's rather unexpected that the value of
log_msgdepends on the way the binary that is running this logging operation was started (i.e. if the stdout of the process is not a terminal,log_msgis not actually colored, as thecoloredcrate checks this before actually coloring the output text).