[wpkg-users] Event Log format

[Charles Gargent]

2009/11/19 Rainer Meier <r.meier at wpkg.org>:
> Hi Charles,
>
> Charles Gargent wrote:
>> Thanks for that, I never really looked at this setting. I have always
>> left in on by default. I will have to test a bit further as to what is
>> going on as it doesnt work. I dont fully understand what the wpkg.js
>> script is doing when it says  "replace new-lines by pipes" on line
>> 5685. Is this a type of newline character in eventlog speak?
>
> Let's first have a look what a multi-line message is. In general a
> message/string is just a series of characters or bytes. So a string might look
> as follows:
>
> "This is a sample message"
>
> Now this message can be multi-line:
>
> "this is a
> sample multiline
> message"
>
> In fact technically both strings are just a series of characters/bytes. Some of
> these bytes are just "non-printable". Non-printable characters are spaces, tabs,
> and of course new-line characters. Windows uses CR/LF (Carriage Return + Line
> Feed) characters while Unix uses LF only and MacOS uses CR only.
>
> The CR character is typically represented as an escaped "r": \r
> The LF character is typically represented as an escaped "n": \n
>
> So on Windows the multi-line message above is stored in machine memory as follows:
>
> "this is a\r\nsmaple multiline\r\nmessage"
>
> The new-lines shown above are just inserted by the program when it displays the
> character. Technically these CR/LF characters are just normal characters in the
> byte-stream.
>
> So what the code you've re-used does is simply to replace any number of CR/LF
> characters by a pipe character. The result shows as follows:
>
> "this is a|smaple multiline|message"
>
> That's all the "magic".
>
>
>> If this
>> is the case then perhaps logparser only deals with one type and not
>> the other.
>>
>> From Helpfile:
>>
>> formatMsg
>>
>> Values: ON | OFF
>>
>> Default: ON
>>
>> Format the text message as a single line.
>>
>> Details: Event text messages often span multiple lines. When this
>> parameter is set to "ON", the EVT input format preserves readability
>> of the messages by removing carriage-return, line-feed, and multiple
>> space characters from the message text.
>> When this parameter is set to "OFF", the EVT input format returns the
>> original message text with no intervening post-processing.
>>
>> Example: -formatMsg:OFF
>
> Oh "... often span multiple lines..." :-) so this confirms that multi-line
> messages are not that uncommon.
>
> According to the description if formatMsg is set to ON, then Log Parser appears
> to do pretty much the same as the the WPKG code and "condenses" multiple lines
> to one. In addition it will remove multiple spaces. Well you could do the same
> using another regular expression. But I decided to preserve spaces on purpose in
> WPKG because it allows to restore the original message while the Microsoft
> approach destroys some data.
>
> For example the following message
>
> "this is
> a multiline message.
> additional data:
>     - some     data
>     - whatever"
>
> will most probably be condensed to
> "this isa multiline message.additional data:- some data- whatever"
> Mabe it inserts spaces instead of just removing newlines:
> "this is a multiline message. additional data: - some data - whatever"
>
> In both cases you will not be able to restore the original message since some
> data obviously has been deleted (you don't know any more if this is an
> "intended" space or has been a CR/LF character replaced by space.
>
> WPKG would translate the message above to:
> "this is|a multiline message.|additional data:|     - some     data|     - whatever"
>
> Re-replacing pipes by CR/LF restores the original message:
> "this is
> a multiline message.
> additional data:
>     - some     data
>     - whatever"
>
>
> However I don't know exactly how Log Parser works but it might be entirely OK
> for its purpose just to "condense" multi-line messages to single lines. In any
> case the result should be at least similar to what you do by WPKG modification
> now. So you might be able to use this Log Parser option instead having to modify
> wpkg.js.
>
> Well, just noticed I (again) wrote quite a lot of explanation which you're
> probably not even interested in. I should write a book with all these
> snipplets... ;-)
>
>
> br,
> Rainer
>

I have had a quick look into this, and it appears that it is a problem
with logparser/eventlogs and nothing to do with wpkg. Most of the time
log parser correctly substitutes the CR LF but every so often it
doesnt. I will post back here if I get any further with it.

Thanks for all your help