On Tue, 20 Jul 2010, Rainer Jung wrote:
message and behind the message. I guess you can get rid of the latter split
by assigning a format specifier also to the log message, like '%M' or
similar, and then
ErrorLogFormat "[%{u}t] [%l] [pid %P%{:tid }T] %F: %{}{: }E%{[client }{] }a
%M %{}{, referer: }i"
Doing it with two config directives was more straightforward to implement,
but I agree that the configuration would be easier to read with a format
specifier for the log message.
Maybe questioning, how important the configurable pre and suffixes are. We
could either provide fixed ones for the individual log patterns, or we could
provide none and indeed log an empty string or "-" if we don't have a value.
I'd say both ways are viable. I guess some users would find it nice to have a
fixed column format until the error message begins, so it's easier to parse
by script, others will find it more readable if the empty fields get
suppressed (condensed format).
What about:
- Allow to choose whether empty values get dropped (one configuration switch
to choose the condensed format)
- taking all adjacent non-whitespace as prefixes and suffixes, collapse
resulting adjacent whitespace in the output by adding the whitespace in front
of the prefix to the prefix and dropping leading whitespace from the
resulting line)
Thats a very interesting idea. Taking it one step further, one could
introduce a meta-character (e.g. ^) for separating the fields. If a format
specifier produces no output, everything from the previous to the next
field separator gets deleted. For example:
ErrorLogFormat "[%{u}t] [%l] [pid %P^:tid %T^] ^%F: ^%E: ^[client %a] ^%M ^,
referer: %{Referer}i"
That's quite readable. I will check how much effort this is to implement.
Cheers,
Stefan
