GNU bug report logs - #20974
Weird newline matching behaviour in --null-data mode

Previous Next

Package: grep;

Reported by: Balazs Kezes <rlblaster <at> gmail.com>

Date: Fri, 3 Jul 2015 17:00:07 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Balazs Kezes <rlblaster <at> gmail.com>
Cc: 20974 <at> debbugs.gnu.org
Subject: bug#20974: Weird newline matching behaviour in --null-data mode
Date: Fri, 3 Jul 2015 20:03:10 -0700
On Fri, Jul 3, 2015 at 9:59 AM, Balazs Kezes <rlblaster <at> gmail.com> 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.




This bug report was last modified 9 years and 328 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.