From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5053 invoked by alias); 15 Sep 2012 20:08:30 -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: 17268 Received: (qmail 29450 invoked from network); 15 Sep 2012 20:08:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: neutral (ns1.primenet.com.au: 74.125.82.171 is neither permitted nor denied by SPF record at ntlworld.com) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-proxyuser-ip:date:from:to:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=TeE33fW3O8snm3spIl0YxFZFWktr8sGIJwqJ/KmXI34=; b=Woukq+aWJc3b1p5uPJt0fKexJb0JNSZNWEHnj9hhZUry81XYgS72JjjknePlydgLth BVpQXPqH1t7mIXvimBIvBnDuHxqmoN4x8HWQVgJSyKm7eTLs2V0slnOgPSfEKPFdW/Vn OnCJc+EQmvDjBSfyvindrhFNC1L+hurrtuhE+Ng/+BUy6uqVqHE8J/ZCcIBlRQbd054d iT3Ua2m86DJ6MxZZZC5ay/gLfi2ZENKIJGhArdLkLmxQrfYWSVoO/9SMmFUwgMRyRfec T3Xf8+Ksu3yrFvEDwrgMqHrgy7uTeWjWgrdhwiKUOdmK1mEB7z2u90eDOGSJgBdPiPLN HQ0Q== X-ProxyUser-IP: 86.6.16.18 Date: Sat, 15 Sep 2012 20:42:46 +0100 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: regex matching regression in 5.0.0 vs. 4.3.17 Message-ID: <20120915204246.0bb41f96@pws-pc.ntlworld.com> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkJXdAY3osFEC1iZmJvWIdY7ir32E9Ol+kvcMd9Phbkc5bieScLSVBcZSv+GiRTmb/RuuG3 On Sat, 15 Sep 2012 17:37:47 +0200 Moritz Bunkus wrote: > parse_git_branch:8: failed to compile regex: Unmatched [ or [^ > > Turned out it didn't like the ${IFS} inside the pattern (never mind > the line number discrepency, I've cut out some other stuff from the > function). This simplifies to [[ x =~ [^${IFS}] ]] The problem is that IFS in zsh contains an ASCII null. As the regular expression is a null-terminated string, it ends at that point, with the error noted. The reason this has changed is that before the patch you noted the null was left encoded as a space with an 8th-bit-set marker before it; it didn't do the right thing, but as it was in a character group you got away with it. So it's actually not a new breakage, just a different one. I'm not aware of any standard way of getting a null character into a regular expression; they don't understand \0 or anything similar, and presumably in any case regexec() hiccups in exactly the same way as regcomp(). Even with pcre [[ $'\x00' =~ '\x00' ]] doesn't work (c.f. $'\x41' and '\x41' which does). So unless anyone can think of a smart solution, I think the only answer is to remove NULL characters from the body of the regular expression and document that this happens. You can do ${IFS//$'\0'} but it's not clear to me you should have to, that use of IFS seems like it ought to work. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/