jtmoon79
commented
2 years ago This also occurs when using grep with colorizing.
grep
Given grep command
$ grep -R /var/log/apt -Fe 'unpack'will colorize the string "unpack" in output
...
Preparing to unpack .../gnupg2_2.2.27-3ubuntu2.1_all.deb ...
Preparing to unpack .../libapt-pkg6.0_2.4.6_amd64.deb ...
...
s4
And running only s4
s4 -wn /var/log/apt/results in
...
term.log.2.gz :Preparing to unpack .../gnupg2_2.2.27-3ubuntu2.1_all.deb ...
term.log.2.gz :Preparing to unpack .../libapt-pkg6.0_2.4.6_amd64.deb ...
...
s4 | grep
But piping s4 output to grep
$ s4 -wn /var/log/apt/ | grep -Fe 'unpack's4 will colorize the printed data. grep colorize the substring "unpack", but grep does not return to the preceding color after the "unpack" substring, so s4 colorizing is interrupted
term.log.2.gz :Preparing to unpack .../gnupg2_2.2.27-3ubuntu2.1_all.deb ...
term.log.2.gz :Preparing to unpack .../libapt-pkg6.0_2.4.6_amd64.deb ...
Noticed while posting this SO Answer,
Errors printed are the same color as the previously printed sysline.
Reproduction
Given some syslog file with multiple syslines, run
Prints
The first line is colorized, which is expected. However, the line
ERROR: failed to print Broken pipe (os error 32)is also colorized. It should be printed with the default text settings.This was run in bash shell within Windows Terminal.
More...
The reason is the shell escape codes to return to default text settings occur after the newline. This escape code to default text settings is written to the pipe
|and thenheaddrops that default text escape code. So the terminal does not see the default text escape code. Thus, proceeding lines retain the same colorization settings as the prior sysline.This relates to a larger problem that user-facing errors are currently handled in a generic way
eprintln!. However, user-facing errors should have awareness ofTermColorsettings, and handle their own colorization. This Issue may require significant refactoring, depending upon the completeness of the solution.