From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4313 invoked by alias); 4 Apr 2017 00:42:21 -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: 22655 Received: (qmail 6549 invoked from network); 4 Apr 2017 00:42:21 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.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(66.111.4.25):SA:0(-0.7/5.0):. Processed in 1.762515 secs); 04 Apr 2017 00:42:21 -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=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FsPe64gC6yCC9Wq2Ln +BvPWqbYuB4Dg6VknLv47v0Jc=; b=UfWk6YtMhBtsZrvNWwhefLMrF/3brWySsK tz04DwRFDNKuuL9oLDMA7TVxc2W/saQ0D7bRfzzT707eLqCgW03Q4yfcRBSh0evN yGqCdRy4+4VdOEP1nRq4AXUUrWMFCG4swDMO2Yf7RCe+Qdwkn3E2CWifSwp5ZTpY 6uSp25qiGMaynu3OOZirs/1sbA7gGIyZJsLBm5V4xK1lqpdeaA63x687TIn+FC85 5sqatepeSoNsMhYkWB1kduxagELjVx/kZ05hLu+UZR+UJZSMUJAnbEOk5rMxI28D 8Sj8ArP4RmDBFs1KPflxQxLMFDUgS9yFWX3wZaAtVaaUldbWaRpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FsPe64gC6yCC9Wq2Ln +BvPWqbYuB4Dg6VknLv47v0Jc=; b=HWv+ALISKDzUhaH+Ubfzg2Rh1WLQ2e92KV 8ZlSZiASdnrdoLwtueTxEiE+3jmAclIgcHVViUs2PPmGwHGYZLZtkjTllGX5IZuj dZcqxGIxBOTfnUljDEOE6sQhcv3jd0K3xlI9Nd6mm6b0O/LHx+QGps033gOip/Z3 8TzeEeSlNdbCMHSL/qWXkiT64KZJPByRmck76M1QPMk+E0bcWAe8UivMuZPu75aI MAXA14tGIE18g1fcuMvAyxdFGUubjyrX+lAVK59SJOTNFfrUHUI0F5CWruhSDLeq 4oWyPU2TmznxJ9coBhXvD+clayWHLXDuMaqOqo95RoYWnIT5BPdA== X-ME-Sender: X-Sasl-enc: 8ge018DLEvkGlXY02pplCXUHBU28uuwWiDcs/9lXwmHk 1491266530 Date: Tue, 4 Apr 2017 00:36:49 +0000 From: Daniel Shahaf To: zsh-users@zsh.org Subject: Re: REMATCH_PCRE with zsh built without pcre support Message-ID: <20170404003649.GA6581@fujitsu.shahaf.local2> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <170403110016.ZM12756@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Mon, Apr 03, 2017 at 11:00:16 -0700: > On Apr 3, 11:26am, Daniel Shahaf wrote: > } > } I agree that semantics of operators shouldn't depend on option > > I'm not even particularly worried about semantic dependency; the gripe > here is that "setopt re_match_pcre" does not succeed (or fail) based on > the presence (or absence) of the module. Exactly how big a problem is > that? If you are relying on =~ having perl semantics, you ought to be > calling "zmodload zsh/pcre" anyway, and not just expecting setopt to do > that for you. Yes, you should load zsh/pcre before using =~ with Perl semantics; setopt won't do that for you. No one is disputing either of these assertions. 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 =~ ? 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 tomorrow morning; before removing that option, we should provide an upgrade path to users who use it correctly (= with 'zmodload -e' checks) and rely on it to continue to work as documented. That's all I was trying to say. I'll step out of this thread for a day or two now. Apologies if I've tested your patience, that wasn't my intention. Cheers, Daniel