2009/11/19 Rainer Meier <r.me...@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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
