Doing this in the httpd server will prevent use-cases of programmatically
parsing the log files. I think the data in the file should support both
use-cases
- Parsing the log file data for data analysis.
- Humans reading the logs.
So, the raw data should support both use-cases.
For a human reading the logs, that should be handled by an application that
parses the raw data and presents it in human readable format. Here is a
simple application:
#!/usr/bin/python
import sys, fileinput
write = sys.stdout.write
separator = '-'*78 + '\n'
for line in fileinput.input():
lines = line.decode("string_escape")
write(lines)
if lines.count('\n') > 1:
write(separator)
You could also have an application with much more functionality,
color-coding fields, using underline to separate records instead of dashes,
whatever you want.
The above application may not meet exactly what the OP wants: but that's my
point: each user's use-case is different, and the raw data should support
all the use-cases.
On Mon, Apr 18, 2016 at 8:28 AM, Stefan Eissing <
[email protected]> wrote:
> Would it make sense to replace \n with \n\t?
>
> > Am 18.04.2016 um 14:23 schrieb Jim Jagielski <[email protected]>:
> >
> > No opinion :)
> >
> >> On Apr 13, 2016, at 3:43 PM, Eric Covener <[email protected]> wrote:
> >>
> >> Currently newlines get backslash-escaped if written to the errorlog.
> >> This is via server/gen_test_char.c and stems from an ancient vuln
> >> about escape sequences in log files potentially affecting peoples
> >> terminals when cat'ed.
> >>
> >> On a few occasions I have worked with some libraries that return a
> >> newline-formatted buffer that I'd love to dump to the error log
> >> without scanning and splitting up into multiple log entries.
> >>
> >> I also occasionally see \n's from third-party mods once in a while.
> >>
> >> Any opinions on punching a hole for \n in T_ESCAPE_LOGITEM?
> >
>
>
