From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19823 invoked by alias); 4 Apr 2017 02:43:44 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22656 Received: (qmail 9451 invoked from network); 4 Apr 2017 02:43:44 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f43.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.43):SA:0(-2.3/5.0):. Processed in 0.930245 secs); 04 Apr 2017 02:43:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_SPAM,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.43 as permitted sender) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=XTL2f7G56cg8VEHu4Uqs/2W4wUdOFvHVr7BWC3rfhIA=; b=IuqTHcdGs9BI1jTCtrsWS+Nm+GERUUOpDZZGmLkzkMrvlpbGekvtYHz953lljDJ4/i cs4OV5qUbErv2xi5ASLWiPeJ0+m2ROxyaoPDR+/nm3yfj3JA2yM+i9JHlw6fandVTz/D gji0XElB3f6RSVDtP81HDVWfgSCOYjKKRxUeHOeZmMmSR4FBk6w+d4Xt39BRE5oRp4jF xWuYPgoYB+jCWG2qAM7aFChIk+f6UTHfYB568pvznJyPnzqUQ4yqrrRrDz1UtbmN7z9l puXYCTKGU2c3bxPkMwqboRcLZ9WFtlIUswLfsGNrES3qQZIJXcww7GsYKQrhb8u/YFLt lkjw== X-Gm-Message-State: AFeK/H00DOE6HEFowK/afHvW8va09I25DzbTfA80j3MUiWZh1HBYLtKAu7ozS7ECgYPEyw== X-Received: by 10.31.58.143 with SMTP id h137mr4134345vka.90.1491273818802; Mon, 03 Apr 2017 19:43:38 -0700 (PDT) From: Bart Schaefer Message-Id: <170403194343.ZM13808@torch.brasslantern.com> Date: Mon, 3 Apr 2017 19:43:43 -0700 In-Reply-To: <20170404003649.GA6581@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: REMATCH_PCRE with zsh built without pcre support" (Apr 4, 12:36am) References: <27c2026c-f760-32b0-e0d5-8c6909346979@gmx.com> <170401145348.ZM30308@torch.brasslantern.com> <20170403011159.GA64116@tower.spodhuis.org> <20170403112611.GA4333@fujitsu.shahaf.local2> <170403110016.ZM12756@torch.brasslantern.com> <20170404003649.GA6581@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: REMATCH_PCRE with zsh built without pcre support MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.