[wpkg-users] Event Log format

[Rainer Meier]

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