Re: regex matching regression in 5.0.0 vs. 4.3.17

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 15 Sep 2012 17:37:47 +0200
Moritz Bunkus <moritz@bunkus.org> 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 <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/