> You are looking for the \G anchor or the A modifier.
Both of these options work great!
I've submitted a patch to the manual page with a note explaining these
options.
Thanks :-)
On Wed, Jun 7, 2017 at 10:13 PM, Nikita Popov wrote:
> On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schultz
> wrote:
On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schultz wrote:
> What do you think about adding another option to preg_match() to allow the
> $offset parameter to be treated as the start anchor?
>
> The manual proposes to do this:
>
> $subject = "abcdef";
> $pattern = '/^def/';
> $offset = 3;
On 07/06/2017 21:03, Rasmus Schultz wrote:
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?
The manual proposes to do this:
$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($patte
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?
The manual proposes to do this:
$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, substr($subject, $offset), $matches);
In oth
On Fri, Jul 8, 2011 at 6:09 PM, Richard Quadling wrote:
> On 8 July 2011 16:31, Mike Robinson wrote:
>> On July-08-11 10:01 AM Rafael Dohms wrote:
>>
>> [snip]
>>
>>> first time using preg_match is a nightmare.
>>
>> IMHO, preg_match is poetry in motion.
>>
>> Going through a million lines of cod
On 8 July 2011 16:31, Mike Robinson wrote:
> On July-08-11 10:01 AM Rafael Dohms wrote:
>
> [snip]
>
>> first time using preg_match is a nightmare.
>
> IMHO, preg_match is poetry in motion.
>
> Going through a million lines of code replacing ereg[i] with preg_match
> because it was deprecated in 5
On July-08-11 10:01 AM Rafael Dohms wrote:
[snip]
> first time using preg_match is a nightmare.
IMHO, preg_match is poetry in motion.
Going through a million lines of code replacing ereg[i] with preg_match
because it was deprecated in 5.3 - *that* is a nightmare.
Best Regards
Mike Robinson
2011/7/8 Rafael Dohms :
> Still, this is preg_match it only returns one match, why should i get
> a array and have to use ugly things like $matches[0] afterwards?
> It just makes for very ugly syntax and extra code, a simple function
> would make this cleaner and more intuitive, first time using
>
Still, this is preg_match it only returns one match, why should i get
a array and have to use ugly things like $matches[0] afterwards?
It just makes for very ugly syntax and extra code, a simple function
would make this cleaner and more intuitive, first time using
preg_match is a nightmare.
--
Ra
Hi Rafael :-),
On 08/07/11 15:18, Rafael Dohms wrote:
On Fri, Jul 8, 2011 at 9:20 AM, Nikita Popov wrote:
The most common use for preg_match is validation:
if (!preg_match('~...~', $string)) { /* do something */ }
Here $matches is not required, only the 0/1 return value of preg_match is of
i
No, you don't need to initialize $matches. It's passed by reference and thus
doesn't need to be initialized.
And as I already said: It is good practice to ensure that preg_match
actually matched something:
if (preg_match(REGEX, $string, $matches)) {
// in here $matches is guaranteed to be defi
On Fri, Jul 8, 2011 at 9:20 AM, Nikita Popov wrote:
> The most common use for preg_match is validation:
>
> if (!preg_match('~...~', $string)) { /* do something */ }
>
> Here $matches is not required, only the 0/1 return value of preg_match is of
> interest.
>
> Furthermore, even if you need $matc
The most common use for preg_match is validation:
if (!preg_match('~...~', $string)) { /* do something */ }
Here $matches is not required, only the 0/1 return value of preg_match is of
interest.
Furthermore, even if you need $matches, you should always combine it with an
if:
if (!preg_match('~.
I was wondering if anyone ever thought of either fixing or writing a
new function that would make preg_match actually work in a way that
made sense?
right now i need to pass in a optional parameter that will receive the
match, in this case one or no match, why should this not be the
function's ret
With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly returns 1
instead of 0 using PHP 5.1.6.
the correct value is 0, yes.
The thing is - I have bui
I know this is weird and off-topic but I hope that someone here can give
me a starting pointer.
With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly ret
16 matches
Mail list logo