Subject: bug#22655: grep -Pz '^' now fails!

From: Aaron Crane <[email-masked]>
Date: Sat, 19 Nov 2016 14:37:59 +0000

Paul Eggert <[email-masked]> wrote:
> Stephane Chazelas wrote:
>> Removing PCRE_MULTILINE (and get back to calling pcre_exec on
>> every record separately) would help except in the cases where the
>> user does:
>>
>> grep -xzP '(?m)a'
>
> I don't think grep can address this problem, as in general that would
> require interpreting the PCRE pattern at run-time and grep should not be
> delving into PCRE internals. Uses of (?m) lead to unspecified behavior in
> grep, and applications should not rely on any particular behavior in this
> area. This is firmly in the Perl tradition, as the Perl documentation for
> this part of the regular expression syntax says "The stability of these
> extensions varies widely. Some ... are experimental and may change without
> warning or be completely removed." Also, the grep manual says that -P "is
> highly experimental". User beware, that's all.

I believe the sense of "stability" in that line of the Perl
documentation is "expected continued availability of that feature in
future versions of Perl". But most of the constructs covered by that
caveat have been unchanged (except for bug fixes) for well over a
decade; and some of them, including (?m) and friends, date to Perl
5.000, released in 1994. I can therefore say with a high degree of
confidence that they aren't going to be removed or changed in future
versions of Perl 5, and I've just removed that outdated notice from
the Perl documentation:

https://perl5.git.perl.org/perl.git/commitdiff/ff8bb4687895e07f822f5227d573c967aa0a4524

(That change should be part of the next stable release of Perl, namely
5.26, expected in May 2017.)

Beyond that, I'm not sure it's ideal to use the Perl documentation as
a comprehensive guide to PCRE: the two implementations are
independent, with slightly differing sets of features, and with known
differences in behaviour on edge cases even for features they share.
So even if Perl did consider constructs like (?m) to be "unstable" or
"unreliable", PCRE's authors and maintainers might take a different
view.

That said, I do accept that there are limits to what grep can
reasonably do here — I certainly wouldn't advocate that it try to
delve into PCRE internals! — and in particular, I recognise that -P is
documented as experimental.

-- 
Aaron Crane ** http://aaroncrane.co.uk/