[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dfa.h / dfa.c diff versus gawk attached
From: |
Tony Abou-Assaleh |
Subject: |
Re: dfa.h / dfa.c diff versus gawk attached |
Date: |
Tue, 23 Oct 2007 02:22:32 -0300 (ADT) |
> > Is there a way to pass grep a pattern with an embedded new lines from the
> > command line? Or do I really have to write some code that uses the dfa
> > directly to test this?
>
> You can always use
>
> grep 'some
> text' file1 ...
It seems that grep treats new lines as pattern separators. The above is
currently equivalent to:
grep -e 'some' -e 'text' file1 ...
I haven't looked yet to see where the interpretation of newlines is done.
Further, man grep for -f states:
"Obtain patterns from FILE, one per line"
We will need to add a meta string representing new lines if we don't want
to break backward compatibility. Another option is to add something
similar to -z but for patterns, but then patterns won't be able to embed
null characters for binary matching.
> I can, MAYBE, split it out into 2 patches: restore-newline-matching
> and cumultaive-bug-fixes, but I don't have the energy for any more than
> that.
Sounds good. Thanks.
> I thought I added a comment. If not, the code is clear enough. A pattern
> of the form ab{0}c is treated by dfa as ab{1}c and incorrectly
> does not match "ac". Regex gets this right. This is the only case I've
> found so far where dfa is broken, but if I find others, at least I now
> have a way to signal the caller.
Ah, I see. I wasn't sure if it was related to this bug or something else.
The good news is that now we can have some test cases :O)
Cheers,
TAA
-----------------------------------------------------
Tony Abou-Assaleh
Email: address@hidden
Web site: http://tony.abou-assaleh.net
----------------------[THE END]----------------------