Hello,
I'm just finding out that ^ and $ no longer work with grep -Pz:
https://unix.stackexchange.com/questions/324263/grep-command-doesnt-support-and-anchors-when-its-with-pz
$ grep -Pz '^'
grep: unescaped ^ or $ not supported with -Pz
Which points to this bug.
Note that, it's not that pcre do
Stephane Chazelas wrote:
Can that bug please be reopened so it can be addressed
differenly (PCRE_MULTILINE removed, PCRE_DOLLAR_ENDONLY added)?
Removing PCRE_MULTILINE will make 'grep' wy slower. Can you think of a way
of fixing the bug that doesn't involve removing PCRE_MULTILINE?
2016-11-18 07:54:29 -0800, Paul Eggert:
> Stephane Chazelas wrote:
> >Can that bug please be reopened so it can be addressed
> >differenly (PCRE_MULTILINE removed, PCRE_DOLLAR_ENDONLY added)?
>
> Removing PCRE_MULTILINE will make 'grep' wy slower. Can you
> think of a way of fixing the bug tha
2016-11-18 16:24:02 +, Stephane Chazelas:
[...]
> Why would it make it slower. AFAICT, PCRE_MULTILINE *adds*
> some overhead. It is really meant to be only about changing the
> behaviour of ^ and $.
[...]
Unsurprisingly,
where ~/a contains the output of find / -print0 (which is
typically what
Stephane Chazelas wrote:
Why would it make it slower. AFAICT, PCRE_MULTILINE *adds*
some overhead.
As I understand it, PCRE_MULTILINE lets 'grep' apply a pattern to an entire
buffer that contains many lines, and this lets PCRE efficiently find the first
match in the whole buffer. If grep does
2016-11-18 08:48:04 -0800, Paul Eggert:
> Stephane Chazelas wrote:
> >Why would it make it slower. AFAICT, PCRE_MULTILINE *adds*
> >some overhead.
>
> As I understand it, PCRE_MULTILINE lets 'grep' apply a pattern to an
> entire buffer that contains many lines, and this lets PCRE
> efficiently fin
2016-11-18 17:06:36 +, Stephane Chazelas:
[...]
> That might have been the case a long time ago, as I remember
> some discussion about it as it explained some wrong information
> in the documentation, but as far as I and gdb can tell, grep
> 2.26 at least call pcre_exec for every line of the in
For the record, the doc/test confusion was fixed by commit
b73296ace186451b096b075461634c153d1fa525
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=b73296ace186451b096b075461634c153d1fa525
See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22655#47
and below about PCRE_MULTILINE.
2016-11-18 17:32:59 +, Stephane Chazelas:
[...]
> And PCRE_MULTILINE now can only improve performance.
[...]
Sorry, I meant "and *removing* PCRE_MULTILINE now can only
improve performance". (and we need to add PCRE_DOLLAR_ENDONLY or
otherwise printf 'a\n\0' | grep -Pz 'a$' would still match).
Stephane Chazelas wrote:
$ time grep -Pz '(?-m)^/' ~/a > /dev/null
It looks like you want "^" to stand for a newline character, not the start of a
line. That is not how grep -z works. -z causes the null byte to be the line
delimiter, and "^" should stand for a position immediately after a nul
2016-11-18 09:47:50 -0800, Paul Eggert:
> Stephane Chazelas wrote:
> >$ time grep -Pz '(?-m)^/' ~/a > /dev/null
>
> It looks like you want "^" to stand for a newline character, not the
> start of a line. That is not how grep -z works. -z causes the null
> byte to be the line delimiter, and "^" sho
Stephane Chazelas wrote:
2016-11-18 08:48:04 -0800, Paul Eggert:
Stephane Chazelas wrote:
Why would it make it slower. AFAICT, PCRE_MULTILINE *adds*
some overhead.
As I understand it, PCRE_MULTILINE lets 'grep' apply a pattern to an
entire buffer that contains many lines, and this lets PCRE
e
12 matches
Mail list logo
