Re: PATCH: zsh/regex and =~

[Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>]

On 2007-05-01 at 22:59 +0100, Peter Stephenson wrote:
> I didn't put RE_MATCH_PCRE on by default; it seems to me to be a
> user choice and having it depend on the shell emulation is more
> confusing than useful.  Similarly, I've made the condition code
> behave identically (apart, obviously, from the module =~ uses)
> whether or not the option is set; if the module you didn't
> ask for is not available, you get an error message rather than
> a different sort of regular expression.

Makes sense.

> I've fixed the doc for =~ and tweaked at least one other minor typo.

English really is my first language.  *cough*
Similarly, regex.c:
 /* if you want Basic syntax, make it an alternative options */

s/options/option/

> I've added the option NO_CASE_MATCH to zsh/regex handling (like bash).
> I don't know enough about the PCRE library to decide whether it's
> sensible to have the same effect there, but if it is that's fine by me.

It is.  If you look at bin_pcre_compile(), you can see that if the -i
option is passed, it ORs in the bitflag PCRE_CASELESS.  Both
bin_pcre_compile() and cond_pcre_match() need the obvious:
  if (!isset(CASEMATCH)) pcre_opts |= PCRE_CASELESS;
at a place of your choosing, before the call to pcre_compile().

You _can_ achieve the same thing using embedded options:

% [[ FoO =~ ^(?i)f([aeiou]+) ]] && print -l $MATCH $match
FoO
oO

but I see no reason to not be as compatible as possible in interpreting
basic behavioural options.  Aside: the embedded options parsing means
that the default stringification by ruby of a regexp type can be
directly parsed by zsh's pcre_compile, a happy accident for me which I
noticed yesterday.

% zrb '/^f([aeiou]+)/' ; print $zrb_value
(?-mix:^f([aeiou]+))
% pcre_compile $zrb_value ; pcre_match faui && print $match
aui

Neat.  :^)

> I've added some debugging code to test for a bad id passed to
> the regex-match handler.  This doesn't do a heck of a lot at
> the moment, but the case statement was looking a bit lonely
> with just one entry.

Doh.  Yes, of course, not something I normally skip.  Thanks.

> I'll commit this even if there are quibbles, to establish either a stick
> in the ground or a line in the sand.  (I asked what the difference
> was and was told one was horizontal and the other vertical.)

You can tell the time by the stick in the ground, on a sunny day, if you
draw lines in the sand to mark the hours.

Doing so accurately obviously requires control of both the horizontal
and the vertical.  I've reached the outer limit of what I'll say on this
topic.