Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Hi Christian,
LOL and thank you a lot for your long reply and the obvious hint ;-) I must
have been pretty tired to not realize this section in the script.

While rusty with Perl (I once wrote some Nagios check scripts in it several
years ago and before there were Icinga and Shinken), I got some test script
working and added my few cases. Unfortunately, I am unable to push these
back upstream (might be PEBKAC), so that I attached the patch to this mail.
Could you please take care of integrating the changes?

Have a nice week!
Philipp

PS: Next week - Linuxtag in Berlin <http://www.linuxtag.org/2013/>! Will
you be there?


2013/5/12 Christian Lohmaier <lohmaier+libreoffice@googlemail.com>

Hi Philipp, *,

On Sun, May 12, 2013 at 9:40 PM, Philipp Riemer <ruderphilipp@gmail.com>
wrote:

Thanks for the link. Uh, Perl...

regular expressions would be mor or less the same in other langauges,
so no difference here. And using something else than perl "just for
the sake of it" would be pointless.

Nevertheless, the important line seems to
be:

($line =~ /\b(?<!\/)[Ee]rror(?!\.)\b/)|| # C make error
[...]
What I want, is to ignore it if there is ... at the end of the string:

You didn't bother to look at the whole file, so I won't bother to
write a long reply right now.

So far I have the following (see <http://perldoc.perl.org/perlre.html>):

(?!\.) matches
(1) a single arbitrary character or

no.

(2) an exclamation mark or

no.

the ? signals a group-matching modifier. i.e. it changes the meaning
of the () block. ?! makes the stuff in () to be a "A zero-width
negative look-ahead assertion."

(3) a dot

yes (and no) - it matches a dot inside the (), but the whole rule says
it should only match the previous part *not* followed by a dot.

Similarily, the (?<!\/) is a "A zero-width negative look-behind assertion"

So the pattern matches Error or error, but only if that [Ee]rror is
not after a / and not before a .

and the \b stands for "boundary" (alphanum on the left and !alphanum on
the
right or the other way around), so obviously both, the tick and the
slash,
are !alphanum (as is the colon, which should still match)...

Nah, you'r tricking yourself again. \b ist a change of \w to \W (not
just alphanum, but also _ and some additional unicode characters) or
the other way round, as you wrote yourself.
But a line like  foo/Error.something would happily match \bError\b -
as the / marks a switch - but it should *not* match.

So maybe the easiest would be to add a "and !(A or B)" to the line to
invalidate a false positive match?

No, see my comment abve about you not looking at the whole file.

There are a bunch of whitelist lines in there, lines that matche the
overall error-marking regexes, that should be *ignore*d (hint, hint
:-))) and not counted as errors.

ciao
Christian

Attachment: 0001-Added-rules-to-capture-more-false-positives-in-log-o.patch
Description: Binary data


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.