On 20.07.2010 21:14, Stefan Fritsch wrote:
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.
Yes, that way the choice between condensed and keeping empty fields is
also back to users. If they mark a prefix or a suffix they get it
removed, if not it will stay always (and we could print "-" for the
missing data).
Regards,
Rainer
