Re: PATCH: =~ regex match

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

On 2007-04-26 at 10:31 +0100, Peter Stephenson wrote:
> I thought about =~ and it seemed to me that since it would be largely
> there for bash compatibility it would be better to do it with the system
> regexp library, which would be more compatible and wouldn't depend on
> optional packages.  It shouldn't be too hard to do.  We probably
> wouldn't support BASH_REMATCH, however.

Bash uses extended regexps, so the PCRE stuff should be vaguely a
superset, although it might be worth adding a different match operator,
overloading with condid, to specify some PCRE options to pcre_compile; I
was thinking sticking another case before CPCRE_PLAIN in cond_pcre_match
which sets pcre_opts and then falls through to the plain case.  That
would mostly affect newline handling.

I was also thinking about how to deal with UTF8, which is another
potential advantage to sticking with PCRE.  Zsh isn't specifically
UTF-8 when in widechar, is it?  Is the "right" way something like
(untested):

#if defined(MULTIBYTE_SUPPORT) && defined(HAVE_NL_LANGINFO) && defined(CODESET)
  {
    static int have_utf8_pcre = -1;

    if (!strcmp(nl_langinfo(CODESET), "UTF-8")) {
      if (have_utf8_pcre == -1) {
        if (pcre_config(PCRE_CONFIG_UTF8, &have_utf8_pcre) {
	  have_utf8_pcre = -2; /* erk, failed to ask */
	}
      }

      if (have_utf8_pcre > 0) {
        pcre_opts |= PCRE_UTF8;
      }
    }
  }
#endif

Which means that in non-UTF-8 multibyte locales, you'll get per-octet
regexps, but in UTF-8 locales, a multibyte zsh with a libpcre also built
with UTF-8 support will let you get "proper" matching.

I'm envious of the =~ operator but that doesn't mean that I want to lose
the funky stuff of PCRE when I use it -- I like negative lookahead
assertions, freak that I am.

As to BASH_REMATCH ... how frowned upon are new zsh options which
auto-set for compatibility?  It wouldn't be hard, since the
infrastructure's all already in place.  Call the zsh option BASH_REMATCH
to set the BASH_REMATCH variable.  :^)

% [[ alphabetical =~ ^a([^a]+)a([^a]+)a ]] && print -l $match
lph
betic

Change the last parameter in cond_pcre_match()'s call to
zpcre_get_substrings() to be non-NULL if the zsh option is set so that a
different receptacle to "match" is set.

If I code this up, is it likely to make it in?  If not, I won't bother
as full bash compatibility isn't so important to me, only having =~.
It's not like POSIX is involved here ...

Thanks,
-Phil