Re: Re: Bug #1683 Updated: Failing to parse/compile a *? pattern.

From: Date: Fri, 09 Jul 1999 13:50:54 +0000
Subject: Re: Re: Bug #1683 Updated: Failing to parse/compile a *? pattern.
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-8244@lists.php.net to get a copy of this message
No, actually, I was referring to stuff that is explained in the regex.7 POSIX spec man page you include with php. Paragraph 9: Within a bracket expression, a collating element (a char- acter, a multi-character sequence that collates as if it were a single character, or a collating-sequence name for either) enclosed in [.' and .]' stands for the sequence of characters of that collating element. The sequence is a single element of the bracket expression's list. A bracket expression containing a multi-character collating element can thus match more than one character, e.g. if the collating sequence includes a `ch' collating element, then the RE `[[.ch.]]*c' matches the first five characters of `chchcc'. But no matter. preg with non-greedy matching will do it, if I can ever make preg work. In my stand alone test program, the preg regexp "/\//" is fine and works. In the actual program I'm trying to replace an egreg with it, it tells me "illegal escape sequence \/". I'm about to give up and let someone else fix this Phorum bug. :) -Jonathan *********** REPLY SEPARATOR *********** On 7/9/99 at 1:41 AM Rasmus Lerdorf wrote: >> Ah ok, thanks. I didn't even see those in the docs. Note ereg doesn't >> also doesn't allow [.gt.] style collating patterns inside a [] character >> class. Perhaps preg will. :) > >As per the docs, the ereg* functions are Posix 1003.2 compliant. You are >basically talking about non-standard Perl abberrations here. The preg* >functions were introduced to try to address some of these, but even with >these it is hard to get all the weird Perlish behaviour. > >-Rasmus --- Jonathan Roy - roy@idle.com - Idle Communications, Inc.

« previous php.dev (#8244) next »