Zsh Mailing List Archive
Messages sorted by:
Re: REMATCH_PCRE with zsh built without pcre support
- X-seq: zsh-users 22656
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: REMATCH_PCRE with zsh built without pcre support
- Date: Mon, 3 Apr 2017 19:43:43 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=XTL2f7G56cg8VEHu4Uqs/2W4wUdOFvHVr7BWC3rfhIA=; b=eOCnJA3Kg2Mus6ix5wa2kN9FmudPjIHdBpRnKPZVpUHYBrzJoGEWlKVunEqDsREhQx uHMWyl+XFb6ETmNW9kHz3cA4yJwIqKuOiJ10+tKK84Mh0x77fCF7Ru1nQ3AyXPOKDLeY IvFTK6S6mK1HlLdjhoJJz+PuOdgD9PFSU0xRd9Zc7CA1I1jNIfBxV6tMVx38iLldE/zN dviwYoyWP3D4yr6HGibsYwhjK1olU281XwE5CFKyZRkNHqnP2kHVfdmmsfd5IOg6cLYI Qu1jwUcMHX5ww8Fp4/vVEo6aJ+98GRSeMeNqkkjdxN/q+6Bmkj/KxFcwOYY++MA2dMQb Y7eg==
- In-reply-to: <20170404003649.GA6581@fujitsu.shahaf.local2>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <email@example.com> <170401145348.ZM30308@torch.brasslantern.com> <20170403011159.GA64116@tower.spodhuis.org> <CAH+w=7YWqmJXHbAf0p2KwDxJqOXVzu7HzCugV0NjFfVYsVGMJw@mail.gmail.com> <20170403112611.GA4333@fujitsu.shahaf.local2> <170403110016.ZM12756@torch.brasslantern.com> <20170404003649.GA6581@fujitsu.shahaf.local2>
On Apr 4, 12:36am, Daniel Shahaf wrote:
} The question is just what should the failure mode be when
} zsh/pcre _should_ have been loaded, but [due to a bug in the user's
} script] hadn't been. Should errflag be set once REMATCH_PCRE is set,
} or at the first affected use of =~ ?
You're correct that this is the question posed at the start of this
thread, but it's not the question I want to answer.
The question I want to answer is: Given that the only reasonable time
to set errflag is at the first affected use of =~ , does that make the
present behavior (i.e., no error) of setopt REMATCH_PCRE so egregiously
wrong that we should get rid of the option itself?
My own answer is "no," but I'm willing to entertain counter-assertions.
I'm also willing to entertain "oh, well, who cares if we muck up the
code a bit more with a module-specfic hack in options.c, let's have
an error at an unreasonable time." I don't think it's a good idea, but
there have been worse ones.
} That's not a trivial question, but the point I was trying to make in my
} previous post is that, while both of us might prefer [for different
} reasons] that REMATCH_PCRE had never been added, we can't just remove it
Certainly one approach would be to always use pcre when it is loaded, and
always use regex when it is not, and only throw an error when neither of
them is available. That would only introduce a problem if someone is
expecting regex semantics out of a pattern that is valid in both cases
but means something else in pcre semantics. I'm not going to give myself
a headache trying to construct an example.
} Apologies if I've tested your patience, that wasn't my intention.
*You* are not who/what's testing my patience, and it wasn't my intent to
give you that impression.
If we go with the module-specific hack in options.c, we should also have
an option-specific hack in Modules/pcre.c so "zmodload -u zsh/pcre" is
an error when REMATCH_PCRE is set. Enforced dependence cuts both ways.
Messages sorted by: