Input Formats

Re: TEXTLINE: and just plain

yellowdog.dave — Wed, 22 Oct 2008 10:05:44 GMT

Hi Brink Then you may want to just do the replace_str I described in my previous post as a pre-process and then take that as input to another logparser. Cheers, Dave

Re: TEXTLINE: and just plain

brinkcm — Tue, 21 Oct 2008 14:05:38 GMT

Any thoughts? If need be I can pre-process the logs before parsing them.

Re: TEXTLINE: and just plain

yellowdog.dave — Tue, 14 Oct 2008 12:01:18 GMT

Hi Brink,

I've just been relooking this and sorry, I messed that one up, I inverted my CR and LF, which then worked for me. The post above will not solve your problem - I am still trying to see what I can do.

Cheers, Dave

Re: TEXTLINE: and just plain

yellowdog.dave — Tue, 14 Oct 2008 07:12:33 GMT

Hi Brink,

I cannot replicate this behaviour on my system, I created a file exactly as you described and I get all the lines in a straight select from it.

My file looks like this - below if you copy and paste this in a HEX editor you will note the setup;

Text

Text1

A straight forward select returns as follows;

C:\projects\logparser>logparser "select * from crlf.txt"
WARNING: Input format not specified - using TEXTLINE input format.
LogFilename                    Index Text
------------------------------ ----- -----
C:\projects\logparser\crlf.txt 1     Text
C:\projects\logparser\crlf.txt 2     -
C:\projects\logparser\crlf.txt 3     -
C:\projects\logparser\crlf.txt 4     -
C:\projects\logparser\crlf.txt 5     Text1

Statistics:
-----------
Elements processed: 5
Elements output:    5
Execution time:     0.06 seconds

I did in another post note that I had similar different behaviour on a TSV file to someone else with the TAB characters - maybe something to do with my O/S or locale etc? I will look further into this.

You may want to try this as a workaround at the moment and see if it works for you.This does an inline manipulation of the unicode characters for you - although you will have to deal with the fact that logparser represents null lines with a - character.

logparser "select replace_str(replace_str(text,'\u000d',''),'\u000a','\u000a\000d') as Tex from crlf.txt" -q:on -i:textline

This does an inline replace - although you will have to deal with the fact that logparser represents null lines with a - character.

If you can give an actual snippet from your log and what exactly you are trying to achieve, we will look into it.

Hope this helps.

Cheers, Dave

TEXTLINE: and just plain

brinkcm — Mon, 13 Oct 2008 18:10:29 GMT

Sorry if this comes across odd, I can't figure out this text editor.

Is there any way to change the delimiting character using TEXTLINE? For instance, the text file has:

Text<CR>

<CR>

More text<CR>

Notepad and Logparser show one blank line between the two lines, but a few editors I use show them as three. I don't think Logparser's doing it wrong, but I'd like to be able to change how it treats those characters. Should I run the text file through some utility that converts CR/LFs to something else? Or just the CRs? I proudly label myself a geek, but I have to admit I've never played with CR/LF much beyond stripping or inserting them en masse via text editor. I can't alter what's in the log file so I need to work around it. I'm comparing one line to another (ie, if X then return the line 6 lines above).

Thanks all.

EDIT: Found this in the patent submission. Yay for Google!

http://www.freepatentsonline.com/y2004/0254919.html

[0137] TEXTLINE: The Text field of this input data format is represented by any single line (separated by CRLF or CR) in the text file.

If I have CRLF, CR, CRLF it should by this web page be processing them as three blank lines. Bug? Misinterpretation?