hvisage
Allow color codes to pass the filter but strip the rest control characters
Colors are handy to attract attention to more fatal messages for example. And I could have color on my metalog created log files by enabling ACCEPT_UNICODE_CONTROL_CHARS. However it then allows all other control characters to pass.
I saw a simple fix for this by editing a single line, 189, in metalog.h. I edited it to look like this: # define ISCTRLCODE(X) (((X) == 0x7f || !(((unsigned char) (X)) & 0x60)) && (X) != 0x1B)
0x1B being the escape character which is needed for color codes.
It seems to do the job (at least on version 20220214). Please carefully review the code snippet as I'm no C programmer at all. ;)
EDIT: Currenly if metalog is set to filter out all the control characters then all the color codes (after the escape character) will be left in the logs. Maybe metalog should try to clean color codes too if filter set to filter all control characters?
That would pass escape sequences for everyone. This should be done in a third ACCEPT_ESCAPE_SEQUENCES branch because color is the responsibility of a log viewer and shouldn't be in the raw log files.
I mostly agree.
color is the responsibility of a log viewer and shouldn't be in the raw log files.
But at different viewpoint: Disabling (filtering) colors should be responsibility of a log viewer.
However since colored logs aren't the default and people don't expect to see color in raw logs, your suggestion of ACCEPT_ESCAPE_SEQUENCES as an opt-in compile-time option is the most sensible way.
Currently if some program sends colored log lines to logger and if ACCEPT_UNICODE_CONTROL_CHARS is disabled metalog leaves "trailing garbage" (the actual color code) after the escape character, which somewhat messes up the log.
This was the actual motivation for me to open this issue. And I thought that the easiest way would to let ANSI-color codes to pass the filter.
So if user wants to filter out all the control characters, should metalog try to filter the color codes after the escape character too? (I updated the opening post too.)
They might not be color sequences and removing them could result in missing information. It would be better to ask the program author to stop sending escape sequences in logs.
Yes. That's certainly a problem. My solution was to let escape character pass the filter to keep my logs intact. I know this is a corner case.
I think your suggestion of adding ACCEPT_ESCAPE_SEQUENCES branch option doesn't add too much complication to the filtering code, and keeps the log files more "raw" thus avoiding filtering too much. Which is great. Gets my vote. ;)