\L lowercase till \E (think vi)
\U uppercase till \E (think vi)
\E end case modification (think vi)
- \Q quote regexp metacharacters till \E
+ \Q quote (disable) regexp metacharacters till \E
If C<use locale> is in effect, the case map used by C<\l>, C<\L>, C<\u>
and <\U> is taken from the current locale. See L<perllocale>.
the price.
You will note that all backslashed metacharacters in Perl are
-alphanumeric, such as C<\b>, C<\w>, C<\n>. Unlike some other regular expression
-languages, there are no backslashed symbols that aren't alphanumeric.
-So anything that looks like \\, \(, \), \E<lt>, \E<gt>, \{, or \} is always
-interpreted as a literal character, not a metacharacter. This makes it
-simple to quote a string that you want to use for a pattern but that
-you are afraid might contain metacharacters. Quote simply all the
+alphanumeric, such as C<\b>, C<\w>, C<\n>. Unlike some other regular
+expression languages, there are no backslashed symbols that aren't
+alphanumeric. So anything that looks like \\, \(, \), \E<lt>, \E<gt>,
+\{, or \} is always interpreted as a literal character, not a
+metacharacter. This was once used in a common idiom to disable or
+quote the special meanings of regular expression metacharacters in a
+string that you want to use for a pattern. Simply quote all the
non-alphanumeric characters:
$pattern =~ s/(\W)/\\$1/g;
-You can also use the builtin quotemeta() function to do this.
-An even easier way to quote metacharacters right in the match operator
-is to say
+Now it is much more common to see either the quotemeta() function or
+the \Q escape sequence used to disable the metacharacters special
+meanings like this:
/$unquoted\Q$quoted\E$unquoted/
=over 10
-=item (?#text)
+=item C<(?#text)>
A comment. The text is ignored. If the C</x> switch is used to enable
whitespace formatting, a simple C<#> will suffice.
-=item (?:regexp)
+=item C<(?:regexp)>
This groups things like "()" but doesn't make backreferences like "()" does. So
but doesn't spit out extra fields.
-=item (?=regexp)
+=item C<(?=regexp)>
A zero-width positive lookahead assertion. For example, C</\w+(?=\t)/>
matches a word followed by a tab, without including the tab in C<$&>.
-=item (?!regexp)
+=item C<(?!regexp)>
A zero-width negative lookahead assertion. For example C</foo(?!bar)/>
matches any occurrence of "foo" that isn't followed by "bar". Note
however that lookahead and lookbehind are NOT the same thing. You cannot
-use this for lookbehind: C</(?!foo)bar/> will not find an occurrence of
-"bar" that is preceded by something which is not "foo". That's because
+use this for lookbehind. If you are looking for a "bar" which isn't preceeded
+"foo", C</(?!foo)bar/> will not do what you want. That's because
the C<(?!foo)> is just saying that the next thing cannot be "foo"--and
it's not, it's a "bar", so "foobar" will match. You would have to do
something like C</(?!foo)...bar/> for that. We say "like" because there's
the case of your "bar" not having three characters before it. You could
-cover that this way: C</(?:(?!foo)...|^..?)bar/>. Sometimes it's still
+cover that this way: C</(?:(?!foo)...|^.{0,2})bar/>. Sometimes it's still
easier just to say:
- if (/foo/ && $` =~ /bar$/)
+ if (/bar/ && $` !~ /foo$/)
+For lookbehind see below.
-=item (?imsx)
+=item C<(?<=regexp)>
+
+A zero-width positive lookbehind assertion. For example, C</(?=\t)\w+/>
+matches a word following a tab, without including the tab in C<$&>.
+Works only for fixed-width lookbehind.
+
+=item C<(?<!regexp)>
+
+A zero-width negative lookbehind assertion. For example C</(?<!bar)foo/>
+matches any occurrence of "foo" that isn't following "bar".
+Works only for fixed-width lookbehind.
+
+=item C<(?{ code })>
+
+Experimental "evaluate any Perl code" zero-width assertion. Always
+succeeds. C<code> is not interpolated. Currently the rules to
+determine where the C<code> ends are somewhat convoluted.
+
+=item C<(?E<gt>regexp)>
+
+An "independend" subexpression. Matches the substring which a
+I<standalone> C<regexp> would match if anchored at the given position,
+B<and only this substring>.
+
+Say, C<^(?E<gt>a*)ab> will never match, since C<(?E<gt>a*)> (anchored
+at the beginning of string, as above) will match I<all> the characters
+C<a> at the beginning of string, leaving no C<a> for C<ab> to match.
+In contrast, C<a*ab> will match the same as C<a+b>, since the match of
+the subgroup C<a*> is influenced by the following group C<ab> (see
+L<"Backtracking">). In particular, C<a*> inside C<a*ab> will match
+less characters that a standalone C<a*>, since this makes the tail match.
+
+Note that a similar effect to C<(?E<gt>regexp)> may be achieved by
+
+ (?=(regexp))\1
+
+since the lookahead is in I<"logical"> context, thus matches the same
+substring as a standalone C<a+>. The following C<\1> eats the matched
+string, thus making a zero-length assertion into an analogue of
+C<(?>...)>. (The difference of these two constructions is that the
+second one uses a catching group, thus shifts ordinals of
+backreferences in the rest of a regular expression.)
+
+This construction is very useful for optimizations of "eternal"
+matches, since it will not backtrack (see L<"Backtracking">). Say,
+
+ / \( (
+ [^()]+
+ |
+ \( [^()]* \)
+ )+
+ \) /x
+
+will match a nonempty group with matching two-or-less-level-deep
+parentheses. It is very efficient in finding such groups. However,
+if there is no such group, it is going to take forever (on reasonably
+long string), since there are so many different ways to split a long
+string into several substrings (this is essentially what C<(.+)+> is
+doing, and this is a subpattern of the above pattern). Say, on
+C<((()aaaaaaaaaaaaaaaaaa> the above pattern detects no-match in 5sec
+(on kitchentop'96 processor), and each extra letter doubles this time.
+
+However, a tiny modification of this
+
+ / \( (
+ (?> [^()]+ )
+ |
+ \( [^()]* \)
+ )+
+ \) /x
+
+which uses (?>...) matches exactly when the above one does (it is a
+good excercise to check this), but finishes in a fourth of the above
+time on a similar string with 1000000 C<a>s.
+
+Note that on simple groups like the above C<(?> [^()]+ )> a similar
+effect may be achieved by negative lookahead, as in C<[^()]+ (?! [^()] )>.
+This was only 4 times slower on a string with 1000000 C<a>s.
+
+=item C<(?(condition)yes-regexp|no-regexp)>
+
+=item C<(?(condition)yes-regexp)>
+
+Conditional expression. C<(condition)> should be either an integer in
+parentheses (which is valid if the corresponding pair of parentheses
+matched), or lookahead/lookbehind/evaluate zero-width assertion.
+
+Say,
+
+ / ( \( )?
+ [^()]+
+ (?(1) \) )/x
+
+matches a chunk of non-parentheses, possibly included in parentheses
+themselves.
+
+=item C<(?imsx)>
One or more embedded pattern-match modifiers. This is particularly
useful for patterns that are specified in a table somewhere, some of
$pattern = "(?i)foobar";
if ( /$pattern/ )
+Note that these modifiers are localized inside an enclosing group (if
+any). Say,
+
+ ( (?i) blah ) \s+ \1
+
+(assuming C<x> modifier, and no C<i> modifier outside of this group)
+will match a repeated (I<including the case>!) word C<blah> in any
+case.
+
=back
The specific choice of question mark for this and the new minimal
=head2 Backtracking
-A fundamental feature of regular expression matching involves the notion
-called I<backtracking>. which is used (when needed) by all regular
-expression quantifiers, namely C<*>, C<*?>, C<+>, C<+?>, C<{n,m}>, and
-C<{n,m}?>.
+A fundamental feature of regular expression matching involves the
+notion called I<backtracking>. which is currently used (when needed)
+by all regular expression quantifiers, namely C<*>, C<*?>, C<+>,
+C<+?>, C<{n,m}>, and C<{n,m}?>.
For a regular expression to match, the I<entire> regular expression must
match, not just part of it. So if the beginning of a pattern containing a
And if you used C<*>'s instead of limiting it to 0 through 5 matches, then
it would take literally forever--or until you ran out of stack space.
+A powerful tool for optimizing such beasts is "independent" groups,
+which do not backtrace (see L<C<(?E<gt>regexp)>>). Note also that
+zero-length lookahead/lookbehind assertions will not backtrace to make
+the tail match, since they are in "logical" context: only the fact
+whether they match or not is considered relevant. For an example
+where side-effects of a lookahead I<might> have influenced the
+following match, see L<C<(?E<gt>regexp)>>.
+
=head2 Version 8 Regular Expressions
In case you're not familiar with the "regular" Version 8 regexp
first character after the "[" is "^", the class matches any character not
in the list. Within a list, the "-" character is used to specify a
range, so that C<a-z> represents all the characters between "a" and "z",
-inclusive.
+inclusive. If you want "-" itself to be a member of a class, put it
+at the start or end of the list, or escape it with a backslash. (The
+following all specify the same class of three characters: C<[-az]>,
+C<[az-]>, and C<[a\-z]>. All are different from C<[a-z]>, which
+specifies a class containing twenty-six characters.)
Characters may be specified using a metacharacter syntax much like that
used in C: "\n" matches a newline, "\t" a tab, "\r" a carriage return,
the last alternative contains everything from the last "|" to the next
pattern delimiter. For this reason, it's common practice to include
alternatives in parentheses, to minimize confusion about where they
-start and end. Note however that "|" is interpreted as a literal with
-square brackets, so if you write C<[fee|fie|foe]> you're really only
-matching C<[feio|]>.
+start and end.
+
+Note that alternatives are tried from left to right, so the first
+alternative found for which the entire expression matches, is the one that
+is chosen. This means that alternatives are not necessarily greedy. For
+example: when mathing C<foo|foot> against "barefoot", only the "foo"
+part will match, as that is the first alternative tried, and it successfully
+matches the target string. (This might not seem important, but it is
+important when you are capturing matched text using parentheses.)
+
+Also note that "|" is interpreted as a literal within square brackets,
+so if you write C<[fee|fie|foe]> you're really only matching C<[feio|]>.
Within a pattern, you may designate subpatterns for later reference by
enclosing them in parentheses, and you may refer back to the I<n>th
C<${1}000>. Basically, the operation of interpolation should not be confused
with the operation of matching a backreference. Certainly they mean two
different things on the I<left> side of the C<s///>.
+
+=head2 SEE ALSO
+
+L<perlop/"Regexp Quote-Like Operators">.
+
+L<perlfunc/pos>.
+
+L<perllocale>.
+
+"Mastering Regular Expressions" (see L<perlbook>) by Jeffrey Friedl.
projects / p5sagit/p5-mst-13.2.git / blobdiff