Unparsable line about dategrep

[mdom]

You can try the switch --multiline, which does not insist to correctly parse every line by itself. If dategrep finds a line that does not match its time formats, the line is just added to the last line that matched.

[3PO]

I dont know, what i do wrong, but it doesnt work:

vdr01_64 ~ # ./dategrep-standalone-big.pl --multiline --start "12:00" --end "12:15" --format "%b %d %H:%M:%S" /log/messages
dategrep-standalone-big.pl: No date found in first line: [parse] Invalid date string
vdr01_64 ~ #

There are entries at at this time in my logfile:

.....
Feb 08 12:08:03 [vdr] epg2vdr: Processed channel 'S19.2E-1-1053-21104' - 'HSE24 HD' with 0 updates
Feb 08 12:08:03 [vdr] epg2vdr: Processed channel 'S19.2E-133-33-40' - 'HSE24' with 3 updates
Feb 08 12:08:03 [vdr] epg2vdr: Processed channel 'S19.2E-1-1007-4911' - 'ORF1 HD' with 1 updates
Feb 08 12:08:03 [vdr] epg2vdr: Processed channel 'S19.2E-1-1117-13001' - 'ORF1' with 1 updates
Feb 08 12:08:03 [vdr] epg2vdr: Processed channel 'S19.2E-133-17-19' - 'Junior' with 4 updates
.....

[mdom]

Mhh, weird, works here for me with the same command line and input file. %b is the abbreviated month name according to the current locale. Do you maybe use a locale that does not abbreviate February to Feb? What's the ouput of locale(1)?

[3PO]

vdr01_64 ~ # locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE=C
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
vdr01_64 ~ #

[mdom]

Ah, i got it. Dategrep checks if the first line of your file contains a date string, which can fail under multiline. I fixed that in the latest commit and you can already download the new prebuild scripts with the modifications. I still have to fix the corresponding code in sort_iterator() but as long as you don't use --sort-files or --interleave, it should now work.

[3PO]

Thanks, no it works as expected. ;)