>On 5/30/07, Jim Lucas <EMAIL REMOVED> wrote:
>
>>The op will need to use something other than forward slashes.

At 5/30/2007 03:26 PM, Jared Farrish wrote:
>You mean the delimiters (a la Richard's suggestion about using '|')?


Hi Jared,

If the pattern delimiter character appears in the pattern it must be
escaped so that the regexp processor will correctly interpret it as a
pattern character and not as the end of the pattern.

This would produce a regexp error:

/ldap://*/

but this is OK:

/ldap:\/\/*/

Therefore if you choose another delimiter altogether you don't have
to escape the slashes:

#ldap://*#

Cleaner and more clear.


>preg_match('|^ldap(s)?://[a-zA-Z0-9-]+\.[a-zA-Z.]{2,5}$|', $this->server )
>>
>>I also recommend using single quotes instead of double quotes here.
>
>Single Quotes: Noted. Any reason why? I guess you might be a little out of
>luck putting $vars into a regex without . concatenating.

Both PHP and regexp use the backslash as an escape. Inside double
quotes, PHP interprets \ as escape, while inside single quotes PHP
interprets \ as a simple backslash character.

When working with regexp in PHP you're dealing with two interpreters,
first PHP and then regexp. To support PHP's interpretation with
double quotes, you have to escape the escapes:

Single quotes: '/ldap:\/\/*/'
Double quotes: "/ldap:\\/\\/*/"

PHP interprets "\\/" as \/
RegExp interprets \/ as /

There's also the additional minor argument that single-quoted strings
take less processing because PHP isn't scanning them for escaped
characters and variables to expand. On a practical level, though,
the difference is going to be measured in microseconds and is
unlikely to affect the perceptible speed of a typical PHP application.

So, for a pattern like this that contains slashes, it's best to use a
non-slash delimiter AND single quotes (unless, as you say, you need
to include PHP variables in the pattern):

$pattern = '#ldap://*#';

Personally I favor heredoc syntax for such situations because I don't
have to worry about the quotes:

$regexp = <<<_
#ldap://*$var#
_;


>>why is there a period in the second pattern?
>
>The period comes from the original article on SitePoint (linked earlier). Is
>it unnecessary? I can't say I'm real sure what this means for the '.' in
>regex's:
>
>"Matches any single character except line break characters \r and \n. Most
>regex flavors have an option to make the dot match line break characters
>too."
>- http://www.regular-expressions.info/reference.html

Inside of a bracketed character cl***, the dot means a literal period
character and not a wildcard.

"All non-alphanumeric characters other than \, -, ^ (at the start)
and the terminating ] are non-special in character cl***es"

PHP PREG
Pattern Syntax
http://www.php.net/manual/en/referen...ern.syntax.php
scroll down to 'Square brackets'


>>Also, why are you allowing for uppercase letters
>>when the RFC's don't allow them?
>
>I hadn't gotten far enough to strtolower(), but that's a good point, I
>hadn't actually considered it yet.

Perhaps it has to do with the source of the string: can you guarantee
that the URIs p***ed to this routine conform to spec?

Another way to handle this would be to simply accept case-insensitive strings:

|^ldap(s)?://[a-z0-9-]+\.[a-z.]{2,5}$|i

Pattern Modifiers
http://www.php.net/manual/en/referen....modifiers.php

"i (PCRE_CASELESS)
" If this modifier is set, letters in the pattern match both upper
and lower case letters."

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

On Thursday 31 May 2007 01:33, Jared Farrish wrote:

> Can anybody spot why this doesn't seem to be working right? The manual
> ( http://us2.php.net/preg_match) says it returns "false" on error, but
> preg_last_error() returns 0, which I ***ume points to the
> "PREG_NO_ERROR" error code.
>
> <code>
> preg_match("^ldap(s)?://[a-zA-Z0-9-]+\.[a-zA-Z.]{2,5}$",$this->server)
> </code>
>
> I also tried ereg(), and have searched and gone through the comments.
> Why would a regex operation return false?

If you check your error log you'll find:

Warning: preg_match(): No ending delimiter '^' found in xxx.php on line xx

IMO that shouldn't be a warning, it should be an error that halts
execution so people wouldn't go looking for a non-existant
preg_last_error() when preg_match() did not even run.

--
Crayon

On Wed, May 30, 2007 4:25 pm, Jared Farrish wrote:
> On 5/30/07, Richard Lynch <EMAIL REMOVED> wrote:
>>
>> If you can't find them documented, print them out:
>>
>> echo "PREG_NO_ERROR: '", PREG_NO_ERROR, '";
>>
>
> Doh!
>
> PREG_NO_ERROR: 0
> PREG_INTERNAL_ERROR: 1
> PREG_BACKTRACK_LIMIT_ERROR: 2
> PREG_RECURSION_LIMIT_ERROR: 3
> PREG_BAD_UTF8_ERROR: 4
>
> So apparently, "PREG_NO_ERROR" is synonymous for "you need delimiters,
> egghead."

I think the error mechanism you are checking never even had a chance
to kick in...

It's kind of like an in-flight warning system for an airplane that
never got off the ground... It's going to keep saying "no error"
while the plane burns to a cinder if it never got turned on in the
first place as it never got in the air.

preg_match("/^ldap(s)?:\/\/([a-zA-Z0-9-])+\.[a-zA-Z.]{2,5}$/",$this->server)
>>
>> Try using | instead of / for your delimiter, so that you don't have
>> to
>> dink around with escaping the / in the pattern...
>
>
> You only have to escape "/" if it's part if it's the pattern
> delimiter?
>
> Makes the code less cluttered and more clear.
>
>
> Fo' sho'.

Yup.

You only need to escape the delimiter you chose if it's in the pattern.

Or, looking at it from the pattern point of view: Pick a delimiter
you are unlikely to ever need in the pattern, so you won't need to
escape it.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On Wed, May 30, 2007 5:04 pm, Jim Lucas wrote:
> btw: why is there a period in the second pattern? Also, why are you
> allowing for uppercase letters
> when the RFC's don't allow them?

LDAP URL domain can't be ALL CAPS?!

Last I heard, domain names were case-insensitive in every other URL...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?