[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20974: Weird newline matching behaviour in --null-data mode
From: |
Jim Meyering |
Subject: |
bug#20974: Weird newline matching behaviour in --null-data mode |
Date: |
Fri, 3 Jul 2015 20:10:08 -0700 |
On Fri, Jul 3, 2015 at 8:03 PM, Jim Meyering <address@hidden> wrote:
> On Fri, Jul 3, 2015 at 9:59 AM, Balazs Kezes <address@hidden> wrote:
>> Hello!
>>
>> I'm running into issues with grep in -z mode. I've managed to minimize
>> it into this:
>>
>> $ seq 2 | grep --null-data --quiet '[12].2' ; echo $?
>> 0
>> $ seq 2 | grep --null-data --quiet '[1-2].2' ; echo $?
>> 1
>
> Thank you for the report.
> I too would like those two commands to work the same way.
> The problem is that when the regular expression contains a
> bracket expression with a range, grep switches from using
> its DFA matcher to relying on regex, but as Norihiro Tanaka
> mentioned, grep's use of the regex matcher with the
> --null-data (-z) option cannot match multi-line results.
>
> One can demonstrate the problem in the C locale too,
> by using a back-reference, since that construct also causes
> grep to use regex:
>
> $ printf '1\n1\n' |LC_ALL=en_US.UTF-8 src/grep -Ezq '1.1'
> $ printf '1\n1\n' |LC_ALL=en_US.UTF-8 src/grep -Ezq '(1).\1'
> [Exit 1]
> $ printf '1\n1\n' |LC_ALL=C src/grep -Ezq '(1).\1'
> [Exit 1]
>
> It'd be great to fix this, but it is not on my short-term radar,
> though I will add some expected-to-fail tests.
Oh, nice! I see that Paul Eggert has just fixed this with
the following patch:
http://git.sv.gnu.org/cgit/grep.git/commit/?id=0e8fda0d880cccd0
So I'm closing this ticket.