Re: REMATCH_PCRE with zsh built without pcre support

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Mon, Apr 03, 2017 at 00:13:00 -0700:
> Phil Pennock wrote:
> > On 2017-04-01 at 14:53 -0700, Bart Schaefer wrote:
> >> I'd personally be more inclined to do away with REMATCH_PCRE and that
> >> =~ special-case entirely, and require explicit use of the -pcre-match
> >> operator (or a shorter equivalent) when you want those semantics.
> >
> > That's a shame.
> 
> To clarify, I'm not advocating any such demotion of PCRE.  However,
> *IF* the presence of the option when the module is not available is
> really a serious problem, then I think the right thing is to remove
> the option, rather than to expand the special case.

I agree that semantics of operators shouldn't depend on option, but I'm
concerned about an upgrade path for people who build with pcre and set
REMATCH_PCRE.

> > I'll have to hunt down that thread and see what I can do about that.
> 
> It's the recent "zregexparse" thread where this came up.  I'm not sure
> there is anything to be done about it; the zsh/regex module would have
> to become part of the default static build, which might have licensing
> consequences.

What would those be?  zsh/regex is BSD licensed.

>

While at it, the docs of REMATCH_PCRE made me think that =~ fell back to
zsh/regex semantics if zsh/pcre were unavailable, which isn't the case
(it just fails — which is good).  Hence:

diff --git a/Doc/Zsh/options.yo b/Doc/Zsh/options.yo
index 1f8d98b..cc6ae2a 100644
--- a/Doc/Zsh/options.yo
+++ b/Doc/Zsh/options.yo
@@ -725,7 +725,8 @@ cindex(regexp, PCRE)
 cindex(PCRE, regexp)
 item(tt(REMATCH_PCRE))(
 If set, regular expression matching with the tt(=~) operator will use
-Perl-Compatible Regular Expressions from the PCRE library, if available.
+Perl-Compatible Regular Expressions from the PCRE library.
+(The tt(zsh/pcre) module must be available.)
 If not set, regular expressions will use the extended regexp syntax
 provided by the system libraries.
 )