1PERLRE(1) Perl Programmers Reference Guide PERLRE(1)
2
6 perlre - Perl regular expressions
7
9 This page describes the syntax of regular expressions in Perl.
10 If you haven't used regular expressions before, a quick-start
12 introduction is available in perlrequick, and a longer tutorial
13 introduction is available in perlretut.
14 For reference on how regular expressions are used in matching
16 operations, plus various examples of the same, see discussions of
17 "m//", "s///", "qr//" and "??" in "Regexp Quote-Like Operators" in
18 perlop.
19 Modifiers
21 Matching operations can have various modifiers. Modifiers that relate
22 to the interpretation of the regular expression inside are listed
23 below. Modifiers that alter the way a regular expression is used by
24 Perl are detailed in "Regexp Quote-Like Operators" in perlop and "Gory
25 details of parsing quoted constructs" in perlop.
26 m Treat string as multiple lines. That is, change "^" and "$" from
28 matching the start or end of the string to matching the start or
29 end of any line anywhere within the string.
30 s Treat string as single line. That is, change "." to match any
32 character whatsoever, even a newline, which normally it would not
33 match.
34 Used together, as /ms, they let the "." match any character
36 whatsoever, while still allowing "^" and "$" to match,
37 respectively, just after and just before newlines within the
38 string.
39 i Do case-insensitive pattern matching.
41 If "use locale" is in effect, the case map is taken from the
43 current locale. See perllocale.
44 x Extend your pattern's legibility by permitting whitespace and
46 comments.
47 p Preserve the string matched such that ${^PREMATCH}, {$^MATCH}, and
49 ${^POSTMATCH} are available for use after matching.
50 g and c
52 Global matching, and keep the Current position after failed
53 matching. Unlike i, m, s and x, these two flags affect the way the
54 regex is used rather than the regex itself. See "Using regular
55 expressions in Perl" in perlretut for further explanation of the g
56 and c modifiers.
57 These are usually written as "the "/x" modifier", even though the
59 delimiter in question might not really be a slash. Any of these
60 modifiers may also be embedded within the regular expression itself
61 using the "(?...)" construct. See below.
62 The "/x" modifier itself needs a little more explanation. It tells the
64 regular expression parser to ignore whitespace that is neither
65 backslashed nor within a character class. You can use this to break up
66 your regular expression into (slightly) more readable parts. The "#"
67 character is also treated as a metacharacter introducing a comment,
68 just as in ordinary Perl code. This also means that if you want real
69 whitespace or "#" characters in the pattern (outside a character class,
70 where they are unaffected by "/x"), then you'll either have to escape
71 them (using backslashes or "\Q...\E") or encode them using octal or hex
72 escapes. Taken together, these features go a long way towards making
73 Perl's regular expressions more readable. Note that you have to be
74 careful not to include the pattern delimiter in the comment--perl has
75 no way of knowing you did not intend to close the pattern early. See
76 the C-comment deletion code in perlop. Also note that anything inside
77 a "\Q...\E" stays unaffected by "/x".
78 Regular Expressions
80 Metacharacters
81 The patterns used in Perl pattern matching evolved from those supplied
83 in the Version 8 regex routines. (The routines are derived (distantly)
84 from Henry Spencer's freely redistributable reimplementation of the V8
85 routines.) See "Version 8 Regular Expressions" for details.
86 In particular the following metacharacters have their standard
88 egrep-ish meanings:
89 \ Quote the next metacharacter
91 ^ Match the beginning of the line
92 . Match any character (except newline)
93 $ Match the end of the line (or before newline at the end)
94 | Alternation
95 () Grouping
96 [] Character class
97 By default, the "^" character is guaranteed to match only the beginning
99 of the string, the "$" character only the end (or before the newline at
100 the end), and Perl does certain optimizations with the assumption that
101 the string contains only one line. Embedded newlines will not be
102 matched by "^" or "$". You may, however, wish to treat a string as a
103 multi-line buffer, such that the "^" will match after any newline
104 within the string (except if the newline is the last character in the
105 string), and "$" will match before any newline. At the cost of a
106 little more overhead, you can do this by using the /m modifier on the
107 pattern match operator. (Older programs did this by setting $*, but
108 this practice has been removed in perl 5.9.)
109 To simplify multi-line substitutions, the "." character never matches a
111 newline unless you use the "/s" modifier, which in effect tells Perl to
112 pretend the string is a single line--even if it isn't.
113 Quantifiers
115 The following standard quantifiers are recognized:
117 * Match 0 or more times
119 + Match 1 or more times
120 ? Match 1 or 0 times
121 {n} Match exactly n times
122 {n,} Match at least n times
123 {n,m} Match at least n but not more than m times
124 (If a curly bracket occurs in any other context, it is treated as a
126 regular character. In particular, the lower bound is not optional.)
127 The "*" quantifier is equivalent to "{0,}", the "+" quantifier to
128 "{1,}", and the "?" quantifier to "{0,1}". n and m are limited to
129 integral values less than a preset limit defined when perl is built.
130 This is usually 32766 on the most common platforms. The actual limit
131 can be seen in the error message generated by code such as this:
132 $_ **= $_ , / {$_} / for 2 .. 42;
134 By default, a quantified subpattern is "greedy", that is, it will match
136 as many times as possible (given a particular starting location) while
137 still allowing the rest of the pattern to match. If you want it to
138 match the minimum number of times possible, follow the quantifier with
139 a "?". Note that the meanings don't change, just the "greediness":
140 *? Match 0 or more times, not greedily
142 +? Match 1 or more times, not greedily
143 ?? Match 0 or 1 time, not greedily
144 {n}? Match exactly n times, not greedily
145 {n,}? Match at least n times, not greedily
146 {n,m}? Match at least n but not more than m times, not greedily
147 By default, when a quantified subpattern does not allow the rest of the
149 overall pattern to match, Perl will backtrack. However, this behaviour
150 is sometimes undesirable. Thus Perl provides the "possessive"
151 quantifier form as well.
152 *+ Match 0 or more times and give nothing back
154 ++ Match 1 or more times and give nothing back
155 ?+ Match 0 or 1 time and give nothing back
156 {n}+ Match exactly n times and give nothing back (redundant)
157 {n,}+ Match at least n times and give nothing back
158 {n,m}+ Match at least n but not more than m times and give nothing back
159 For instance,
161 'aaaa' =~ /a++a/
163 will never match, as the "a++" will gobble up all the "a"'s in the
165 string and won't leave any for the remaining part of the pattern. This
166 feature can be extremely useful to give perl hints about where it
167 shouldn't backtrack. For instance, the typical "match a double-quoted
168 string" problem can be most efficiently performed when written as:
169 /"(?:[^"\\]++|\\.)*+"/
171 as we know that if the final quote does not match, backtracking will
173 not help. See the independent subexpression "(?>...)" for more details;
174 possessive quantifiers are just syntactic sugar for that construct. For
175 instance the above example could also be written as follows:
176 /"(?>(?:(?>[^"\\]+)|\\.)*)"/
178 Escape sequences
180 Because patterns are processed as double quoted strings, the following
182 also work:
183 \t tab (HT, TAB)
185 \n newline (LF, NL)
186 \r return (CR)
187 \f form feed (FF)
188 \a alarm (bell) (BEL)
189 \e escape (think troff) (ESC)
190 \033 octal char (example: ESC)
191 \x1B hex char (example: ESC)
192 \x{263a} long hex char (example: Unicode SMILEY)
193 \cK control char (example: VT)
194 \N{name} named Unicode character
195 \l lowercase next char (think vi)
196 \u uppercase next char (think vi)
197 \L lowercase till \E (think vi)
198 \U uppercase till \E (think vi)
199 \E end case modification (think vi)
200 \Q quote (disable) pattern metacharacters till \E
201 If "use locale" is in effect, the case map used by "\l", "\L", "\u" and
203 "\U" is taken from the current locale. See perllocale. For
204 documentation of "\N{name}", see charnames.
205 You cannot include a literal "$" or "@" within a "\Q" sequence. An
207 unescaped "$" or "@" interpolates the corresponding variable, while
208 escaping will cause the literal string "\$" to be matched. You'll need
209 to write something like "m/\Quser\E\@\Qhost/".
210 Character Classes and other Special Escapes
212 In addition, Perl defines the following:
214 \w Match a "word" character (alphanumeric plus "_")
216 \W Match a non-"word" character
217 \s Match a whitespace character
218 \S Match a non-whitespace character
219 \d Match a digit character
220 \D Match a non-digit character
221 \pP Match P, named property. Use \p{Prop} for longer names.
222 \PP Match non-P
223 \X Match eXtended Unicode "combining character sequence",
224 equivalent to (?>\PM\pM*)
225 \C Match a single C char (octet) even under Unicode.
226 NOTE: breaks up characters into their UTF-8 bytes,
227 so you may end up with malformed pieces of UTF-8.
228 Unsupported in lookbehind.
229 \1 Backreference to a specific group.
230 '1' may actually be any positive integer.
231 \g1 Backreference to a specific or previous group,
232 \g{-1} number may be negative indicating a previous buffer and may
233 optionally be wrapped in curly brackets for safer parsing.
234 \g{name} Named backreference
235 \k<name> Named backreference
236 \K Keep the stuff left of the \K, don't include it in $&
237 \v Vertical whitespace
238 \V Not vertical whitespace
239 \h Horizontal whitespace
240 \H Not horizontal whitespace
241 \R Linebreak
242 A "\w" matches a single alphanumeric character (an alphabetic
244 character, or a decimal digit) or "_", not a whole word. Use "\w+" to
245 match a string of Perl-identifier characters (which isn't the same as
246 matching an English word). If "use locale" is in effect, the list of
247 alphabetic characters generated by "\w" is taken from the current
248 locale. See perllocale. You may use "\w", "\W", "\s", "\S", "\d", and
249 "\D" within character classes, but they aren't usable as either end of
250 a range. If any of them precedes or follows a "-", the "-" is
251 understood literally. If Unicode is in effect, "\s" matches also
252 "\x{85}", "\x{2028}", and "\x{2029}". See perlunicode for more details
253 about "\pP", "\PP", "\X" and the possibility of defining your own "\p"
254 and "\P" properties, and perluniintro about Unicode in general.
255 "\R" will atomically match a linebreak, including the network line-
257 ending "\x0D\x0A". Specifically, is exactly equivalent to
258 (?>\x0D\x0A?|[\x0A-\x0C\x85\x{2028}\x{2029}])
260 Note: "\R" has no special meaning inside of a character class; use "\v"
262 instead (vertical whitespace).
263 The POSIX character class syntax
265 [:class:]
267 is also available. Note that the "[" and "]" brackets are literal;
269 they must always be used within a character class expression.
270 # this is correct:
272 $string =~ /[[:alpha:]]/;
273 # this is not, and will generate a warning:
275 $string =~ /[:alpha:]/;
276 The available classes and their backslash equivalents (if available)
278 are as follows:
279 alpha
281 alnum
282 ascii
283 blank [1]
284 cntrl
285 digit \d
286 graph
287 lower
288 print
289 punct
290 space \s [2]
291 upper
292 word \w [3]
293 xdigit
294 [1] A GNU extension equivalent to "[ \t]", "all horizontal whitespace".
296 [2] Not exactly equivalent to "\s" since the "[[:space:]]" includes
298 also the (very rare) "vertical tabulator", "\cK" or chr(11) in
299 ASCII.
300 [3] A Perl extension, see above.
302 For example use "[:upper:]" to match all the uppercase characters.
304 Note that the "[]" are part of the "[::]" construct, not part of the
305 whole character class. For example:
306 [01[:alpha:]%]
308 matches zero, one, any alphabetic character, and the percent sign.
310 The following equivalences to Unicode \p{} constructs and equivalent
312 backslash character classes (if available), will hold:
313 [[:...:]] \p{...} backslash
315 alpha IsAlpha
317 alnum IsAlnum
318 ascii IsASCII
319 blank
320 cntrl IsCntrl
321 digit IsDigit \d
322 graph IsGraph
323 lower IsLower
324 print IsPrint (but see [2] below)
325 punct IsPunct (but see [3] below)
326 space IsSpace
327 IsSpacePerl \s
328 upper IsUpper
329 word IsWord \w
330 xdigit IsXDigit
331 For example "[[:lower:]]" and "\p{IsLower}" are equivalent.
333 However, the equivalence between "[[:xxxxx:]]" and "\p{IsXxxxx}" is not
335 exact.
336 [1] If the "utf8" pragma is not used but the "locale" pragma is, the
338 classes correlate with the usual isalpha(3) interface (except for
339 "word" and "blank").
340 But if the "locale" or "encoding" pragmas are not used and the
342 string is not "utf8", then "[[:xxxxx:]]" (and "\w", etc.) will not
343 match characters 0x80-0xff; whereas "\p{IsXxxxx}" will force the
344 string to "utf8" and can match these characters (as Unicode).
345 [2] "\p{IsPrint}" matches characters 0x09-0x0d but "[[:print:]]" does
347 not.
348 [3] "[[:punct::]]" matches the following but "\p{IsPunct}" does not,
350 because they are classed as symbols (not punctuation) in Unicode.
351 "$" Currency symbol
353 "+" "<" "=" ">" "|" "~"
355 Mathematical symbols
356 "^" "`"
358 Modifier symbols (accents)
359 The other named classes are:
361 cntrl
363 Any control character. Usually characters that don't produce
364 output as such but instead control the terminal somehow: for
365 example newline and backspace are control characters. All
366 characters with ord() less than 32 are usually classified as
367 control characters (assuming ASCII, the ISO Latin character sets,
368 and Unicode), as is the character with the ord() value of 127
369 ("DEL").
370 graph
372 Any alphanumeric or punctuation (special) character.
373 print
375 Any alphanumeric or punctuation (special) character or the space
376 character.
377 punct
379 Any punctuation (special) character.
380 xdigit
382 Any hexadecimal digit. Though this may feel silly ([0-9A-Fa-f]
383 would work just fine) it is included for completeness.
384 You can negate the [::] character classes by prefixing the class name
386 with a '^'. This is a Perl extension. For example:
387 POSIX traditional Unicode
389 [[:^digit:]] \D \P{IsDigit}
391 [[:^space:]] \S \P{IsSpace}
392 [[:^word:]] \W \P{IsWord}
393 Perl respects the POSIX standard in that POSIX character classes are
395 only supported within a character class. The POSIX character classes
396 [.cc.] and [=cc=] are recognized but not supported and trying to use
397 them will cause an error.
398 Assertions
400 Perl defines the following zero-width assertions:
402 \b Match a word boundary
404 \B Match except at a word boundary
405 \A Match only at beginning of string
406 \Z Match only at end of string, or before newline at the end
407 \z Match only at end of string
408 \G Match only at pos() (e.g. at the end-of-match position
409 of prior m//g)
410 A word boundary ("\b") is a spot between two characters that has a "\w"
412 on one side of it and a "\W" on the other side of it (in either order),
413 counting the imaginary characters off the beginning and end of the
414 string as matching a "\W". (Within character classes "\b" represents
415 backspace rather than a word boundary, just as it normally does in any
416 double-quoted string.) The "\A" and "\Z" are just like "^" and "$",
417 except that they won't match multiple times when the "/m" modifier is
418 used, while "^" and "$" will match at every internal line boundary. To
419 match the actual end of the string and not ignore an optional trailing
420 newline, use "\z".
421 The "\G" assertion can be used to chain global matches (using "m//g"),
423 as described in "Regexp Quote-Like Operators" in perlop. It is also
424 useful when writing "lex"-like scanners, when you have several patterns
425 that you want to match against consequent substrings of your string,
426 see the previous reference. The actual location where "\G" will match
427 can also be influenced by using "pos()" as an lvalue: see "pos" in
428 perlfunc. Note that the rule for zero-length matches is modified
429 somewhat, in that contents to the left of "\G" is not counted when
430 determining the length of the match. Thus the following will not match
431 forever:
432 $str = 'ABC';
434 pos($str) = 1;
435 while (/.\G/g) {
436 print $&;
437 }
438 It will print 'A' and then terminate, as it considers the match to be
440 zero-width, and thus will not match at the same position twice in a
441 row.
442 It is worth noting that "\G" improperly used can result in an infinite
444 loop. Take care when using patterns that include "\G" in an
445 alternation.
446 Capture buffers
448 The bracketing construct "( ... )" creates capture buffers. To refer to
450 the current contents of a buffer later on, within the same pattern, use
451 \1 for the first, \2 for the second, and so on. Outside the match use
452 "$" instead of "\". (The \<digit> notation works in certain
453 circumstances outside the match. See the warning below about \1 vs $1
454 for details.) Referring back to another part of the match is called a
455 backreference.
456 There is no limit to the number of captured substrings that you may
458 use. However Perl also uses \10, \11, etc. as aliases for \010, \011,
459 etc. (Recall that 0 means octal, so \011 is the character at number 9
460 in your coded character set; which would be the 10th character, a
461 horizontal tab under ASCII.) Perl resolves this ambiguity by
462 interpreting \10 as a backreference only if at least 10 left
463 parentheses have opened before it. Likewise \11 is a backreference
464 only if at least 11 left parentheses have opened before it. And so on.
465 \1 through \9 are always interpreted as backreferences.
466 In order to provide a safer and easier way to construct patterns using
468 backreferences, Perl provides the "\g{N}" notation (starting with perl
469 5.10.0). The curly brackets are optional, however omitting them is less
470 safe as the meaning of the pattern can be changed by text (such as
471 digits) following it. When N is a positive integer the "\g{N}" notation
472 is exactly equivalent to using normal backreferences. When N is a
473 negative integer then it is a relative backreference referring to the
474 previous N'th capturing group. When the bracket form is used and N is
475 not an integer, it is treated as a reference to a named buffer.
476 Thus "\g{-1}" refers to the last buffer, "\g{-2}" refers to the buffer
478 before that. For example:
479 /
481 (Y) # buffer 1
482 ( # buffer 2
483 (X) # buffer 3
484 \g{-1} # backref to buffer 3
485 \g{-3} # backref to buffer 1
486 )
487 /x
488 and would match the same as "/(Y) ( (X) \3 \1 )/x".
490 Additionally, as of Perl 5.10.0 you may use named capture buffers and
492 named backreferences. The notation is "(?<name>...)" to declare and
493 "\k<name>" to reference. You may also use apostrophes instead of angle
494 brackets to delimit the name; and you may use the bracketed "\g{name}"
495 backreference syntax. It's possible to refer to a named capture buffer
496 by absolute and relative number as well. Outside the pattern, a named
497 capture buffer is available via the "%+" hash. When different buffers
498 within the same pattern have the same name, $+{name} and "\k<name>"
499 refer to the leftmost defined group. (Thus it's possible to do things
500 with named capture buffers that would otherwise require "(??{})" code
501 to accomplish.)
502 Examples:
504 s/^([^ ]*) *([^ ]*)/$2 $1/; # swap first two words
506 /(.)\1/ # find first doubled char
508 and print "'$1' is the first doubled character\n";
509 /(?<char>.)\k<char>/ # ... a different way
511 and print "'$+{char}' is the first doubled character\n";
512 /(?'char'.)\1/ # ... mix and match
514 and print "'$1' is the first doubled character\n";
515 if (/Time: (..):(..):(..)/) { # parse out values
517 $hours = $1;
518 $minutes = $2;
519 $seconds = $3;
520 }
521 Several special variables also refer back to portions of the previous
523 match. $+ returns whatever the last bracket match matched. $& returns
524 the entire matched string. (At one point $0 did also, but now it
525 returns the name of the program.) "$`" returns everything before the
526 matched string. "$'" returns everything after the matched string. And
527 $^N contains whatever was matched by the most-recently closed group
528 (submatch). $^N can be used in extended patterns (see below), for
529 example to assign a submatch to a variable.
530 The numbered match variables ($1, $2, $3, etc.) and the related
532 punctuation set ($+, $&, "$`", "$'", and $^N) are all dynamically
533 scoped until the end of the enclosing block or until the next
534 successful match, whichever comes first. (See "Compound Statements" in
535 perlsyn.)
536 NOTE: Failed matches in Perl do not reset the match variables, which
538 makes it easier to write code that tests for a series of more specific
539 cases and remembers the best match.
540 WARNING: Once Perl sees that you need one of $&, "$`", or "$'" anywhere
542 in the program, it has to provide them for every pattern match. This
543 may substantially slow your program. Perl uses the same mechanism to
544 produce $1, $2, etc, so you also pay a price for each pattern that
545 contains capturing parentheses. (To avoid this cost while retaining
546 the grouping behaviour, use the extended regular expression "(?: ... )"
547 instead.) But if you never use $&, "$`" or "$'", then patterns without
548 capturing parentheses will not be penalized. So avoid $&, "$'", and
549 "$`" if you can, but if you can't (and some algorithms really
550 appreciate them), once you've used them once, use them at will, because
551 you've already paid the price. As of 5.005, $& is not so costly as the
552 other two.
553 As a workaround for this problem, Perl 5.10.0 introduces
555 "${^PREMATCH}", "${^MATCH}" and "${^POSTMATCH}", which are equivalent
556 to "$`", $& and "$'", except that they are only guaranteed to be
557 defined after a successful match that was executed with the "/p"
558 (preserve) modifier. The use of these variables incurs no global
559 performance penalty, unlike their punctuation char equivalents, however
560 at the trade-off that you have to tell perl when you want to use them.
561 Backslashed metacharacters in Perl are alphanumeric, such as "\b",
563 "\w", "\n". Unlike some other regular expression languages, there are
564 no backslashed symbols that aren't alphanumeric. So anything that
565 looks like \\, \(, \), \<, \>, \{, or \} is always interpreted as a
566 literal character, not a metacharacter. This was once used in a common
567 idiom to disable or quote the special meanings of regular expression
568 metacharacters in a string that you want to use for a pattern. Simply
569 quote all non-"word" characters:
570 $pattern =~ s/(\W)/\\$1/g;
572 (If "use locale" is set, then this depends on the current locale.)
574 Today it is more common to use the quotemeta() function or the "\Q"
575 metaquoting escape sequence to disable all metacharacters' special
576 meanings like this:
577 /$unquoted\Q$quoted\E$unquoted/
579 Beware that if you put literal backslashes (those not inside
581 interpolated variables) between "\Q" and "\E", double-quotish backslash
582 interpolation may lead to confusing results. If you need to use
583 literal backslashes within "\Q...\E", consult "Gory details of parsing
584 quoted constructs" in perlop.
585 Extended Patterns
587 Perl also defines a consistent extension syntax for features not found
588 in standard tools like awk and lex. The syntax is a pair of
589 parentheses with a question mark as the first thing within the
590 parentheses. The character after the question mark indicates the
591 extension.
592 The stability of these extensions varies widely. Some have been part
594 of the core language for many years. Others are experimental and may
595 change without warning or be completely removed. Check the
596 documentation on an individual feature to verify its current status.
597 A question mark was chosen for this and for the minimal-matching
599 construct because 1) question marks are rare in older regular
600 expressions, and 2) whenever you see one, you should stop and
601 "question" exactly what is going on. That's psychology...
602 "(?#text)"
604 A comment. The text is ignored. If the "/x" modifier
605 enables whitespace formatting, a simple "#" will suffice.
606 Note that Perl closes the comment as soon as it sees a ")",
607 so there is no way to put a literal ")" in the comment.
608 "(?pimsx-imsx)"
610 One or more embedded pattern-match modifiers, to be turned on
611 (or turned off, if preceded by "-") for the remainder of the
612 pattern or the remainder of the enclosing pattern group (if
613 any). This is particularly useful for dynamic patterns, such
614 as those read in from a configuration file, taken from an
615 argument, or specified in a table somewhere. Consider the
616 case where some patterns want to be case sensitive and some
617 do not: The case insensitive ones merely need to include
618 "(?i)" at the front of the pattern. For example:
619 $pattern = "foobar";
621 if ( /$pattern/i ) { }
622 # more flexible:
624 $pattern = "(?i)foobar";
626 if ( /$pattern/ ) { }
627 These modifiers are restored at the end of the enclosing
629 group. For example,
630 ( (?i) blah ) \s+ \1
632 will match "blah" in any case, some spaces, and an exact
634 (including the case!) repetition of the previous word,
635 assuming the "/x" modifier, and no "/i" modifier outside this
636 group.
637 Note that the "p" modifier is special in that it can only be
639 enabled, not disabled, and that its presence anywhere in a
640 pattern has a global effect. Thus "(?-p)" and "(?-p:...)" are
641 meaningless and will warn when executed under "use warnings".
642 "(?:pattern)"
644 "(?imsx-imsx:pattern)"
645 This is for clustering, not capturing; it groups
646 subexpressions like "()", but doesn't make backreferences as
647 "()" does. So
648 @fields = split(/\b(?:a|b|c)\b/)
650 is like
652 @fields = split(/\b(a|b|c)\b/)
654 but doesn't spit out extra fields. It's also cheaper not to
656 capture characters if you don't need to.
657 Any letters between "?" and ":" act as flags modifiers as
659 with "(?imsx-imsx)". For example,
660 /(?s-i:more.*than).*million/i
662 is equivalent to the more verbose
664 /(?:(?s-i)more.*than).*million/i
666 "(?|pattern)"
668 This is the "branch reset" pattern, which has the special
669 property that the capture buffers are numbered from the same
670 starting point in each alternation branch. It is available
671 starting from perl 5.10.0.
672 Capture buffers are numbered from left to right, but inside
674 this construct the numbering is restarted for each branch.
675 The numbering within each branch will be as normal, and any
677 buffers following this construct will be numbered as though
678 the construct contained only one branch, that being the one
679 with the most capture buffers in it.
680 This construct will be useful when you want to capture one of
682 a number of alternative matches.
683 Consider the following pattern. The numbers underneath show
685 in which buffer the captured content will be stored.
686 # before ---------------branch-reset----------- after
688 / ( a ) (?| x ( y ) z | (p (q) r) | (t) u (v) ) ( z ) /x
689 # 1 2 2 3 2 3 4
690 Note: as of Perl 5.10.0, branch resets interfere with the
692 contents of the "%+" hash, that holds named captures.
693 Consider using "%-" instead.
694 Look-Around Assertions
696 Look-around assertions are zero width patterns which match a
697 specific pattern without including it in $&. Positive
698 assertions match when their subpattern matches, negative
699 assertions match when their subpattern fails. Look-behind
700 matches text up to the current match position, look-ahead
701 matches text following the current match position.
702 "(?=pattern)"
704 A zero-width positive look-ahead assertion. For example,
705 "/\w+(?=\t)/" matches a word followed by a tab, without
706 including the tab in $&.
707 "(?!pattern)"
709 A zero-width negative look-ahead assertion. For example
710 "/foo(?!bar)/" matches any occurrence of "foo" that isn't
711 followed by "bar". Note however that look-ahead and
712 look-behind are NOT the same thing. You cannot use this
713 for look-behind.
714 If you are looking for a "bar" that isn't preceded by a
716 "foo", "/(?!foo)bar/" will not do what you want. That's
717 because the "(?!foo)" is just saying that the next thing
718 cannot be "foo"--and it's not, it's a "bar", so "foobar"
719 will match. You would have to do something like
720 "/(?!foo)...bar/" for that. We say "like" because
721 there's the case of your "bar" not having three
722 characters before it. You could cover that this way:
723 "/(?:(?!foo)...|^.{0,2})bar/". Sometimes it's still
724 easier just to say:
725 if (/bar/ && $` !~ /foo$/)
727 For look-behind see below.
729 "(?<=pattern)" "\K"
731 A zero-width positive look-behind assertion. For
732 example, "/(?<=\t)\w+/" matches a word that follows a
733 tab, without including the tab in $&. Works only for
734 fixed-width look-behind.
735 There is a special form of this construct, called "\K",
737 which causes the regex engine to "keep" everything it had
738 matched prior to the "\K" and not include it in $&. This
739 effectively provides variable length look-behind. The use
740 of "\K" inside of another look-around assertion is
741 allowed, but the behaviour is currently not well defined.
742 For various reasons "\K" may be significantly more
744 efficient than the equivalent "(?<=...)" construct, and
745 it is especially useful in situations where you want to
746 efficiently remove something following something else in
747 a string. For instance
748 s/(foo)bar/$1/g;
750 can be rewritten as the much more efficient
752 s/foo\Kbar//g;
754 "(?<!pattern)"
756 A zero-width negative look-behind assertion. For example
757 "/(?<!bar)foo/" matches any occurrence of "foo" that does
758 not follow "bar". Works only for fixed-width look-
759 behind.
760 "(?'NAME'pattern)"
762 "(?<NAME>pattern)"
763 A named capture buffer. Identical in every respect to normal
764 capturing parentheses "()" but for the additional fact that
765 "%+" or "%-" may be used after a successful match to refer to
766 a named buffer. See "perlvar" for more details on the "%+"
767 and "%-" hashes.
768 If multiple distinct capture buffers have the same name then
770 the $+{NAME} will refer to the leftmost defined buffer in the
771 match.
772 The forms "(?'NAME'pattern)" and "(?<NAME>pattern)" are
774 equivalent.
775 NOTE: While the notation of this construct is the same as the
777 similar function in .NET regexes, the behavior is not. In
778 Perl the buffers are numbered sequentially regardless of
779 being named or not. Thus in the pattern
780 /(x)(?<foo>y)(z)/
782 $+{foo} will be the same as $2, and $3 will contain 'z'
784 instead of the opposite which is what a .NET regex hacker
785 might expect.
786 Currently NAME is restricted to simple identifiers only. In
788 other words, it must match "/^[_A-Za-z][_A-Za-z0-9]*\z/" or
789 its Unicode extension (see utf8), though it isn't extended by
790 the locale (see perllocale).
791 NOTE: In order to make things easier for programmers with
793 experience with the Python or PCRE regex engines, the pattern
794 "(?PE<lt>NAMEE<gt>pattern)" may be used instead of
795 "(?<NAME>pattern)"; however this form does not support the
796 use of single quotes as a delimiter for the name.
797 "\k<NAME>"
799 "\k'NAME'"
800 Named backreference. Similar to numeric backreferences,
801 except that the group is designated by name and not number.
802 If multiple groups have the same name then it refers to the
803 leftmost defined group in the current match.
804 It is an error to refer to a name not defined by a
806 "(?<NAME>)" earlier in the pattern.
807 Both forms are equivalent.
809 NOTE: In order to make things easier for programmers with
811 experience with the Python or PCRE regex engines, the pattern
812 "(?P=NAME)" may be used instead of "\k<NAME>".
813 "(?{ code })"
815 WARNING: This extended regular expression feature is
816 considered experimental, and may be changed without notice.
817 Code executed that has side effects may not perform
818 identically from version to version due to the effect of
819 future optimisations in the regex engine.
820 This zero-width assertion evaluates any embedded Perl code.
822 It always succeeds, and its "code" is not interpolated.
823 Currently, the rules to determine where the "code" ends are
824 somewhat convoluted.
825 This feature can be used together with the special variable
827 $^N to capture the results of submatches in variables without
828 having to keep track of the number of nested parentheses. For
829 example:
830 $_ = "The brown fox jumps over the lazy dog";
832 /the (\S+)(?{ $color = $^N }) (\S+)(?{ $animal = $^N })/i;
833 print "color = $color, animal = $animal\n";
834 Inside the "(?{...})" block, $_ refers to the string the
836 regular expression is matching against. You can also use
837 "pos()" to know what is the current position of matching
838 within this string.
839 The "code" is properly scoped in the following sense: If the
841 assertion is backtracked (compare "Backtracking"), all
842 changes introduced after "local"ization are undone, so that
843 $_ = 'a' x 8;
845 m<
846 (?{ $cnt = 0 }) # Initialize $cnt.
847 (
848 a
849 (?{
850 local $cnt = $cnt + 1; # Update $cnt, backtracking-safe.
851 })
852 )*
853 aaaa
854 (?{ $res = $cnt }) # On success copy to non-localized
855 # location.
856 >x;
857 will set "$res = 4". Note that after the match, $cnt returns
859 to the globally introduced value, because the scopes that
860 restrict "local" operators are unwound.
861 This assertion may be used as a
863 "(?(condition)yes-pattern|no-pattern)" switch. If not used
864 in this way, the result of evaluation of "code" is put into
865 the special variable $^R. This happens immediately, so $^R
866 can be used from other "(?{ code })" assertions inside the
867 same regular expression.
868 The assignment to $^R above is properly localized, so the old
870 value of $^R is restored if the assertion is backtracked;
871 compare "Backtracking".
872 Due to an unfortunate implementation issue, the Perl code
874 contained in these blocks is treated as a compile time
875 closure that can have seemingly bizarre consequences when
876 used with lexically scoped variables inside of subroutines or
877 loops. There are various workarounds for this, including
878 simply using global variables instead. If you are using this
879 construct and strange results occur then check for the use of
880 lexically scoped variables.
881 For reasons of security, this construct is forbidden if the
883 regular expression involves run-time interpolation of
884 variables, unless the perilous "use re 'eval'" pragma has
885 been used (see re), or the variables contain results of
886 "qr//" operator (see "qr/STRING/imosx" in perlop).
887 This restriction is due to the wide-spread and remarkably
889 convenient custom of using run-time determined strings as
890 patterns. For example:
891 $re = <>;
893 chomp $re;
894 $string =~ /$re/;
895 Before Perl knew how to execute interpolated code within a
897 pattern, this operation was completely safe from a security
898 point of view, although it could raise an exception from an
899 illegal pattern. If you turn on the "use re 'eval'", though,
900 it is no longer secure, so you should only do so if you are
901 also using taint checking. Better yet, use the carefully
902 constrained evaluation within a Safe compartment. See
903 perlsec for details about both these mechanisms.
904 Because Perl's regex engine is currently not re-entrant,
906 interpolated code may not invoke the regex engine either
907 directly with "m//" or "s///"), or indirectly with functions
908 such as "split".
909 "(??{ code })"
911 WARNING: This extended regular expression feature is
912 considered experimental, and may be changed without notice.
913 Code executed that has side effects may not perform
914 identically from version to version due to the effect of
915 future optimisations in the regex engine.
916 This is a "postponed" regular subexpression. The "code" is
918 evaluated at run time, at the moment this subexpression may
919 match. The result of evaluation is considered as a regular
920 expression and matched as if it were inserted instead of this
921 construct. Note that this means that the contents of capture
922 buffers defined inside an eval'ed pattern are not available
923 outside of the pattern, and vice versa, there is no way for
924 the inner pattern to refer to a capture buffer defined
925 outside. Thus,
926 ('a' x 100)=~/(??{'(.)' x 100})/
928 will match, it will not set $1.
930 The "code" is not interpolated. As before, the rules to
932 determine where the "code" ends are currently somewhat
933 convoluted.
934 The following pattern matches a parenthesized group:
936 $re = qr{
938 \(
939 (?:
940 (?> [^()]+ ) # Non-parens without backtracking
941 |
942 (??{ $re }) # Group with matching parens
943 )*
944 \)
945 }x;
946 See also "(?PARNO)" for a different, more efficient way to
948 accomplish the same task.
949 Because perl's regex engine is not currently re-entrant,
951 delayed code may not invoke the regex engine either directly
952 with "m//" or "s///"), or indirectly with functions such as
953 "split".
954 Recursing deeper than 50 times without consuming any input
956 string will result in a fatal error. The maximum depth is
957 compiled into perl, so changing it requires a custom build.
958 "(?PARNO)" "(?-PARNO)" "(?+PARNO)" "(?R)" "(?0)"
960 Similar to "(??{ code })" except it does not involve
961 compiling any code, instead it treats the contents of a
962 capture buffer as an independent pattern that must match at
963 the current position. Capture buffers contained by the
964 pattern will have the value as determined by the outermost
965 recursion.
966 PARNO is a sequence of digits (not starting with 0) whose
968 value reflects the paren-number of the capture buffer to
969 recurse to. "(?R)" recurses to the beginning of the whole
970 pattern. "(?0)" is an alternate syntax for "(?R)". If PARNO
971 is preceded by a plus or minus sign then it is assumed to be
972 relative, with negative numbers indicating preceding capture
973 buffers and positive ones following. Thus "(?-1)" refers to
974 the most recently declared buffer, and "(?+1)" indicates the
975 next buffer to be declared. Note that the counting for
976 relative recursion differs from that of relative
977 backreferences, in that with recursion unclosed buffers are
978 included.
979 The following pattern matches a function foo() which may
981 contain balanced parentheses as the argument.
982 $re = qr{ ( # paren group 1 (full function)
984 foo
985 ( # paren group 2 (parens)
986 \(
987 ( # paren group 3 (contents of parens)
988 (?:
989 (?> [^()]+ ) # Non-parens without backtracking
990 |
991 (?2) # Recurse to start of paren group 2
992 )*
993 )
994 \)
995 )
996 )
997 }x;
998 If the pattern was used as follows
1000 'foo(bar(baz)+baz(bop))'=~/$re/
1002 and print "\$1 = $1\n",
1003 "\$2 = $2\n",
1004 "\$3 = $3\n";
1005 the output produced should be the following:
1007 $1 = foo(bar(baz)+baz(bop))
1009 $2 = (bar(baz)+baz(bop))
1010 $3 = bar(baz)+baz(bop)
1011 If there is no corresponding capture buffer defined, then it
1013 is a fatal error. Recursing deeper than 50 times without
1014 consuming any input string will also result in a fatal error.
1015 The maximum depth is compiled into perl, so changing it
1016 requires a custom build.
1017 The following shows how using negative indexing can make it
1019 easier to embed recursive patterns inside of a "qr//"
1020 construct for later use:
1021 my $parens = qr/(\((?:[^()]++|(?-1))*+\))/;
1023 if (/foo $parens \s+ + \s+ bar $parens/x) {
1024 # do something here...
1025 }
1026 Note that this pattern does not behave the same way as the
1028 equivalent PCRE or Python construct of the same form. In Perl
1029 you can backtrack into a recursed group, in PCRE and Python
1030 the recursed into group is treated as atomic. Also, modifiers
1031 are resolved at compile time, so constructs like (?i:(?1)) or
1032 (?:(?i)(?1)) do not affect how the sub-pattern will be
1033 processed.
1034 "(?&NAME)"
1036 Recurse to a named subpattern. Identical to "(?PARNO)" except
1037 that the parenthesis to recurse to is determined by name. If
1038 multiple parentheses have the same name, then it recurses to
1039 the leftmost.
1040 It is an error to refer to a name that is not declared
1042 somewhere in the pattern.
1043 NOTE: In order to make things easier for programmers with
1045 experience with the Python or PCRE regex engines the pattern
1046 "(?P>NAME)" may be used instead of "(?&NAME)".
1047 "(?(condition)yes-pattern|no-pattern)"
1049 "(?(condition)yes-pattern)"
1050 Conditional expression. "(condition)" should be either an
1051 integer in parentheses (which is valid if the corresponding
1052 pair of parentheses matched), a
1053 look-ahead/look-behind/evaluate zero-width assertion, a name
1054 in angle brackets or single quotes (which is valid if a
1055 buffer with the given name matched), or the special symbol
1056 (R) (true when evaluated inside of recursion or eval).
1057 Additionally the R may be followed by a number, (which will
1058 be true when evaluated when recursing inside of the
1059 appropriate group), or by &NAME, in which case it will be
1060 true only when evaluated during recursion in the named group.
1061 Here's a summary of the possible predicates:
1063 (1) (2) ...
1065 Checks if the numbered capturing buffer has matched
1066 something.
1067 (<NAME>) ('NAME')
1069 Checks if a buffer with the given name has matched
1070 something.
1071 (?{ CODE })
1073 Treats the code block as the condition.
1074 (R) Checks if the expression has been evaluated inside of
1076 recursion.
1077 (R1) (R2) ...
1079 Checks if the expression has been evaluated while
1080 executing directly inside of the n-th capture group. This
1081 check is the regex equivalent of
1082 if ((caller(0))[3] eq 'subname') { ... }
1084 In other words, it does not check the full recursion
1086 stack.
1087 (R&NAME)
1089 Similar to "(R1)", this predicate checks to see if we're
1090 executing directly inside of the leftmost group with a
1091 given name (this is the same logic used by "(?&NAME)" to
1092 disambiguate). It does not check the full stack, but only
1093 the name of the innermost active recursion.
1094 (DEFINE)
1096 In this case, the yes-pattern is never directly executed,
1097 and no no-pattern is allowed. Similar in spirit to
1098 "(?{0})" but more efficient. See below for details.
1099 For example:
1101 m{ ( \( )?
1103 [^()]+
1104 (?(1) \) )
1105 }x
1106 matches a chunk of non-parentheses, possibly included in
1108 parentheses themselves.
1109 A special form is the "(DEFINE)" predicate, which never
1111 executes directly its yes-pattern, and does not allow a no-
1112 pattern. This allows to define subpatterns which will be
1113 executed only by using the recursion mechanism. This way,
1114 you can define a set of regular expression rules that can be
1115 bundled into any pattern you choose.
1116 It is recommended that for this usage you put the DEFINE
1118 block at the end of the pattern, and that you name any
1119 subpatterns defined within it.
1120 Also, it's worth noting that patterns defined this way
1122 probably will not be as efficient, as the optimiser is not
1123 very clever about handling them.
1124 An example of how this might be used is as follows:
1126 /(?<NAME>(?&NAME_PAT))(?<ADDR>(?&ADDRESS_PAT))
1128 (?(DEFINE)
1129 (?<NAME_PAT>....)
1130 (?<ADRESS_PAT>....)
1131 )/x
1132 Note that capture buffers matched inside of recursion are not
1134 accessible after the recursion returns, so the extra layer of
1135 capturing buffers is necessary. Thus $+{NAME_PAT} would not
1136 be defined even though $+{NAME} would be.
1137 "(?>pattern)"
1139 An "independent" subexpression, one which matches the
1140 substring that a standalone "pattern" would match if anchored
1141 at the given position, and it matches nothing other than this
1142 substring. This construct is useful for optimizations of
1143 what would otherwise be "eternal" matches, because it will
1144 not backtrack (see "Backtracking"). It may also be useful in
1145 places where the "grab all you can, and do not give anything
1146 back" semantic is desirable.
1147 For example: "^(?>a*)ab" will never match, since "(?>a*)"
1149 (anchored at the beginning of string, as above) will match
1150 all characters "a" at the beginning of string, leaving no "a"
1151 for "ab" to match. In contrast, "a*ab" will match the same
1152 as "a+b", since the match of the subgroup "a*" is influenced
1153 by the following group "ab" (see "Backtracking"). In
1154 particular, "a*" inside "a*ab" will match fewer characters
1155 than a standalone "a*", since this makes the tail match.
1156 An effect similar to "(?>pattern)" may be achieved by writing
1158 "(?=(pattern))\1". This matches the same substring as a
1159 standalone "a+", and the following "\1" eats the matched
1160 string; it therefore makes a zero-length assertion into an
1161 analogue of "(?>...)". (The difference between these two
1162 constructs is that the second one uses a capturing group,
1163 thus shifting ordinals of backreferences in the rest of a
1164 regular expression.)
1165 Consider this pattern:
1167 m{ \(
1169 (
1170 [^()]+ # x+
1171 |
1172 \( [^()]* \)
1173 )+
1174 \)
1175 }x
1176 That will efficiently match a nonempty group with matching
1178 parentheses two levels deep or less. However, if there is no
1179 such group, it will take virtually forever on a long string.
1180 That's because there are so many different ways to split a
1181 long string into several substrings. This is what "(.+)+" is
1182 doing, and "(.+)+" is similar to a subpattern of the above
1183 pattern. Consider how the pattern above detects no-match on
1184 "((()aaaaaaaaaaaaaaaaaa" in several seconds, but that each
1185 extra letter doubles this time. This exponential performance
1186 will make it appear that your program has hung. However, a
1187 tiny change to this pattern
1188 m{ \(
1190 (
1191 (?> [^()]+ ) # change x+ above to (?> x+ )
1192 |
1193 \( [^()]* \)
1194 )+
1195 \)
1196 }x
1197 which uses "(?>...)" matches exactly when the one above does
1199 (verifying this yourself would be a productive exercise), but
1200 finishes in a fourth the time when used on a similar string
1201 with 1000000 "a"s. Be aware, however, that this pattern
1202 currently triggers a warning message under the "use warnings"
1203 pragma or -w switch saying it "matches null string many times
1204 in regex".
1205 On simple groups, such as the pattern "(?> [^()]+ )", a
1207 comparable effect may be achieved by negative look-ahead, as
1208 in "[^()]+ (?! [^()] )". This was only 4 times slower on a
1209 string with 1000000 "a"s.
1210 The "grab all you can, and do not give anything back"
1212 semantic is desirable in many situations where on the first
1213 sight a simple "()*" looks like the correct solution.
1214 Suppose we parse text with comments being delimited by "#"
1215 followed by some optional (horizontal) whitespace. Contrary
1216 to its appearance, "#[ \t]*" is not the correct subexpression
1217 to match the comment delimiter, because it may "give up" some
1218 whitespace if the remainder of the pattern can be made to
1219 match that way. The correct answer is either one of these:
1220 (?>#[ \t]*)
1222 #[ \t]*(?![ \t])
1223 For example, to grab non-empty comments into $1, one should
1225 use either one of these:
1226 / (?> \# [ \t]* ) ( .+ ) /x;
1228 / \# [ \t]* ( [^ \t] .* ) /x;
1229 Which one you pick depends on which of these expressions
1231 better reflects the above specification of comments.
1232 In some literature this construct is called "atomic matching"
1234 or "possessive matching".
1235 Possessive quantifiers are equivalent to putting the item
1237 they are applied to inside of one of these constructs. The
1238 following equivalences apply:
1239 Quantifier Form Bracketing Form
1241 --------------- ---------------
1242 PAT*+ (?>PAT*)
1243 PAT++ (?>PAT+)
1244 PAT?+ (?>PAT?)
1245 PAT{min,max}+ (?>PAT{min,max})
1246 Special Backtracking Control Verbs
1248 WARNING: These patterns are experimental and subject to change or
1249 removal in a future version of Perl. Their usage in production code
1250 should be noted to avoid problems during upgrades.
1251 These special patterns are generally of the form "(*VERB:ARG)". Unless
1253 otherwise stated the ARG argument is optional; in some cases, it is
1254 forbidden.
1255 Any pattern containing a special backtracking verb that allows an
1257 argument has the special behaviour that when executed it sets the
1258 current packages' $REGERROR and $REGMARK variables. When doing so the
1259 following rules apply:
1260 On failure, the $REGERROR variable will be set to the ARG value of the
1262 verb pattern, if the verb was involved in the failure of the match. If
1263 the ARG part of the pattern was omitted, then $REGERROR will be set to
1264 the name of the last "(*MARK:NAME)" pattern executed, or to TRUE if
1265 there was none. Also, the $REGMARK variable will be set to FALSE.
1266 On a successful match, the $REGERROR variable will be set to FALSE, and
1268 the $REGMARK variable will be set to the name of the last
1269 "(*MARK:NAME)" pattern executed. See the explanation for the
1270 "(*MARK:NAME)" verb below for more details.
1271 NOTE: $REGERROR and $REGMARK are not magic variables like $1 and most
1273 other regex related variables. They are not local to a scope, nor
1274 readonly, but instead are volatile package variables similar to
1275 $AUTOLOAD. Use "local" to localize changes to them to a specific scope
1276 if necessary.
1277 If a pattern does not contain a special backtracking verb that allows
1279 an argument, then $REGERROR and $REGMARK are not touched at all.
1280 Verbs that take an argument
1282 "(*PRUNE)" "(*PRUNE:NAME)"
1283 This zero-width pattern prunes the backtracking tree at the
1284 current point when backtracked into on failure. Consider the
1285 pattern "A (*PRUNE) B", where A and B are complex patterns.
1286 Until the "(*PRUNE)" verb is reached, A may backtrack as
1287 necessary to match. Once it is reached, matching continues in
1288 B, which may also backtrack as necessary; however, should B not
1289 match, then no further backtracking will take place, and the
1290 pattern will fail outright at the current starting position.
1291 The following example counts all the possible matching strings
1293 in a pattern (without actually matching any of them).
1294 'aaab' =~ /a+b?(?{print "$&\n"; $count++})(*FAIL)/;
1296 print "Count=$count\n";
1297 which produces:
1299 aaab
1301 aaa
1302 aa
1303 a
1304 aab
1305 aa
1306 a
1307 ab
1308 a
1309 Count=9
1310 If we add a "(*PRUNE)" before the count like the following
1312 'aaab' =~ /a+b?(*PRUNE)(?{print "$&\n"; $count++})(*FAIL)/;
1314 print "Count=$count\n";
1315 we prevent backtracking and find the count of the longest
1317 matching at each matching starting point like so:
1318 aaab
1320 aab
1321 ab
1322 Count=3
1323 Any number of "(*PRUNE)" assertions may be used in a pattern.
1325 See also "(?>pattern)" and possessive quantifiers for other
1327 ways to control backtracking. In some cases, the use of
1328 "(*PRUNE)" can be replaced with a "(?>pattern)" with no
1329 functional difference; however, "(*PRUNE)" can be used to
1330 handle cases that cannot be expressed using a "(?>pattern)"
1331 alone.
1332 "(*SKIP)" "(*SKIP:NAME)"
1334 This zero-width pattern is similar to "(*PRUNE)", except that
1335 on failure it also signifies that whatever text that was
1336 matched leading up to the "(*SKIP)" pattern being executed
1337 cannot be part of any match of this pattern. This effectively
1338 means that the regex engine "skips" forward to this position on
1339 failure and tries to match again, (assuming that there is
1340 sufficient room to match).
1341 The name of the "(*SKIP:NAME)" pattern has special
1343 significance. If a "(*MARK:NAME)" was encountered while
1344 matching, then it is that position which is used as the "skip
1345 point". If no "(*MARK)" of that name was encountered, then the
1346 "(*SKIP)" operator has no effect. When used without a name the
1347 "skip point" is where the match point was when executing the
1348 (*SKIP) pattern.
1349 Compare the following to the examples in "(*PRUNE)", note the
1351 string is twice as long:
1352 'aaabaaab' =~ /a+b?(*SKIP)(?{print "$&\n"; $count++})(*FAIL)/;
1354 print "Count=$count\n";
1355 outputs
1357 aaab
1359 aaab
1360 Count=2
1361 Once the 'aaab' at the start of the string has matched, and the
1363 "(*SKIP)" executed, the next starting point will be where the
1364 cursor was when the "(*SKIP)" was executed.
1365 "(*MARK:NAME)" "(*:NAME)" "(*MARK:NAME)" "(*:NAME)"
1367 This zero-width pattern can be used to mark the point reached
1368 in a string when a certain part of the pattern has been
1369 successfully matched. This mark may be given a name. A later
1370 "(*SKIP)" pattern will then skip forward to that point if
1371 backtracked into on failure. Any number of "(*MARK)" patterns
1372 are allowed, and the NAME portion is optional and may be
1373 duplicated.
1374 In addition to interacting with the "(*SKIP)" pattern,
1376 "(*MARK:NAME)" can be used to "label" a pattern branch, so that
1377 after matching, the program can determine which branches of the
1378 pattern were involved in the match.
1379 When a match is successful, the $REGMARK variable will be set
1381 to the name of the most recently executed "(*MARK:NAME)" that
1382 was involved in the match.
1383 This can be used to determine which branch of a pattern was
1385 matched without using a separate capture buffer for each
1386 branch, which in turn can result in a performance improvement,
1387 as perl cannot optimize "/(?:(x)|(y)|(z))/" as efficiently as
1388 something like "/(?:x(*MARK:x)|y(*MARK:y)|z(*MARK:z))/".
1389 When a match has failed, and unless another verb has been
1391 involved in failing the match and has provided its own name to
1392 use, the $REGERROR variable will be set to the name of the most
1393 recently executed "(*MARK:NAME)".
1394 See "(*SKIP)" for more details.
1396 As a shortcut "(*MARK:NAME)" can be written "(*:NAME)".
1398 "(*THEN)" "(*THEN:NAME)"
1400 This is similar to the "cut group" operator "::" from Perl 6.
1401 Like "(*PRUNE)", this verb always matches, and when backtracked
1402 into on failure, it causes the regex engine to try the next
1403 alternation in the innermost enclosing group (capturing or
1404 otherwise).
1405 Its name comes from the observation that this operation
1407 combined with the alternation operator ("|") can be used to
1408 create what is essentially a pattern-based if/then/else block:
1409 ( COND (*THEN) FOO | COND2 (*THEN) BAR | COND3 (*THEN) BAZ )
1411 Note that if this operator is used and NOT inside of an
1413 alternation then it acts exactly like the "(*PRUNE)" operator.
1414 / A (*PRUNE) B /
1416 is the same as
1418 / A (*THEN) B /
1420 but
1422 / ( A (*THEN) B | C (*THEN) D ) /
1424 is not the same as
1426 / ( A (*PRUNE) B | C (*PRUNE) D ) /
1428 as after matching the A but failing on the B the "(*THEN)" verb
1430 will backtrack and try C; but the "(*PRUNE)" verb will simply
1431 fail.
1432 "(*COMMIT)"
1434 This is the Perl 6 "commit pattern" "<commit>" or ":::". It's a
1435 zero-width pattern similar to "(*SKIP)", except that when
1436 backtracked into on failure it causes the match to fail
1437 outright. No further attempts to find a valid match by
1438 advancing the start pointer will occur again. For example,
1439 'aaabaaab' =~ /a+b?(*COMMIT)(?{print "$&\n"; $count++})(*FAIL)/;
1441 print "Count=$count\n";
1442 outputs
1444 aaab
1446 Count=1
1447 In other words, once the "(*COMMIT)" has been entered, and if
1449 the pattern does not match, the regex engine will not try any
1450 further matching on the rest of the string.
1451 Verbs without an argument
1453 "(*FAIL)" "(*F)"
1454 This pattern matches nothing and always fails. It can be used
1455 to force the engine to backtrack. It is equivalent to "(?!)",
1456 but easier to read. In fact, "(?!)" gets optimised into
1457 "(*FAIL)" internally.
1458 It is probably useful only when combined with "(?{})" or
1460 "(??{})".
1461 "(*ACCEPT)"
1463 WARNING: This feature is highly experimental. It is not
1464 recommended for production code.
1465 This pattern matches nothing and causes the end of successful
1467 matching at the point at which the "(*ACCEPT)" pattern was
1468 encountered, regardless of whether there is actually more to
1469 match in the string. When inside of a nested pattern, such as
1470 recursion, or in a subpattern dynamically generated via
1471 "(??{})", only the innermost pattern is ended immediately.
1472 If the "(*ACCEPT)" is inside of capturing buffers then the
1474 buffers are marked as ended at the point at which the
1475 "(*ACCEPT)" was encountered. For instance:
1476 'AB' =~ /(A (A|B(*ACCEPT)|C) D)(E)/x;
1478 will match, and $1 will be "AB" and $2 will be "B", $3 will not
1480 be set. If another branch in the inner parentheses were
1481 matched, such as in the string 'ACDE', then the "D" and "E"
1482 would have to be matched as well.
1483 Backtracking
1485 NOTE: This section presents an abstract approximation of regular
1486 expression behavior. For a more rigorous (and complicated) view of the
1487 rules involved in selecting a match among possible alternatives, see
1488 "Combining RE Pieces".
1489 A fundamental feature of regular expression matching involves the
1491 notion called backtracking, which is currently used (when needed) by
1492 all regular non-possessive expression quantifiers, namely "*", "*?",
1493 "+", "+?", "{n,m}", and "{n,m}?". Backtracking is often optimized
1494 internally, but the general principle outlined here is valid.
1495 For a regular expression to match, the entire regular expression must
1497 match, not just part of it. So if the beginning of a pattern
1498 containing a quantifier succeeds in a way that causes later parts in
1499 the pattern to fail, the matching engine backs up and recalculates the
1500 beginning part--that's why it's called backtracking.
1501 Here is an example of backtracking: Let's say you want to find the
1503 word following "foo" in the string "Food is on the foo table.":
1504 $_ = "Food is on the foo table.";
1506 if ( /\b(foo)\s+(\w+)/i ) {
1507 print "$2 follows $1.\n";
1508 }
1509 When the match runs, the first part of the regular expression
1511 ("\b(foo)") finds a possible match right at the beginning of the
1512 string, and loads up $1 with "Foo". However, as soon as the matching
1513 engine sees that there's no whitespace following the "Foo" that it had
1514 saved in $1, it realizes its mistake and starts over again one
1515 character after where it had the tentative match. This time it goes
1516 all the way until the next occurrence of "foo". The complete regular
1517 expression matches this time, and you get the expected output of "table
1518 follows foo."
1519 Sometimes minimal matching can help a lot. Imagine you'd like to match
1521 everything between "foo" and "bar". Initially, you write something
1522 like this:
1523 $_ = "The food is under the bar in the barn.";
1525 if ( /foo(.*)bar/ ) {
1526 print "got <$1>\n";
1527 }
1528 Which perhaps unexpectedly yields:
1530 got <d is under the bar in the >
1532 That's because ".*" was greedy, so you get everything between the first
1534 "foo" and the last "bar". Here it's more effective to use minimal
1535 matching to make sure you get the text between a "foo" and the first
1536 "bar" thereafter.
1537 if ( /foo(.*?)bar/ ) { print "got <$1>\n" }
1539 got <d is under the >
1540 Here's another example. Let's say you'd like to match a number at the
1542 end of a string, and you also want to keep the preceding part of the
1543 match. So you write this:
1544 $_ = "I have 2 numbers: 53147";
1546 if ( /(.*)(\d*)/ ) { # Wrong!
1547 print "Beginning is <$1>, number is <$2>.\n";
1548 }
1549 That won't work at all, because ".*" was greedy and gobbled up the
1551 whole string. As "\d*" can match on an empty string the complete
1552 regular expression matched successfully.
1553 Beginning is <I have 2 numbers: 53147>, number is <>.
1555 Here are some variants, most of which don't work:
1557 $_ = "I have 2 numbers: 53147";
1559 @pats = qw{
1560 (.*)(\d*)
1561 (.*)(\d+)
1562 (.*?)(\d*)
1563 (.*?)(\d+)
1564 (.*)(\d+)$
1565 (.*?)(\d+)$
1566 (.*)\b(\d+)$
1567 (.*\D)(\d+)$
1568 };
1569 for $pat (@pats) {
1571 printf "%-12s ", $pat;
1572 if ( /$pat/ ) {
1573 print "<$1> <$2>\n";
1574 } else {
1575 print "FAIL\n";
1576 }
1577 }
1578 That will print out:
1580 (.*)(\d*) <I have 2 numbers: 53147> <>
1582 (.*)(\d+) <I have 2 numbers: 5314> <7>
1583 (.*?)(\d*) <> <>
1584 (.*?)(\d+) <I have > <2>
1585 (.*)(\d+)$ <I have 2 numbers: 5314> <7>
1586 (.*?)(\d+)$ <I have 2 numbers: > <53147>
1587 (.*)\b(\d+)$ <I have 2 numbers: > <53147>
1588 (.*\D)(\d+)$ <I have 2 numbers: > <53147>
1589 As you see, this can be a bit tricky. It's important to realize that a
1591 regular expression is merely a set of assertions that gives a
1592 definition of success. There may be 0, 1, or several different ways
1593 that the definition might succeed against a particular string. And if
1594 there are multiple ways it might succeed, you need to understand
1595 backtracking to know which variety of success you will achieve.
1596 When using look-ahead assertions and negations, this can all get even
1598 trickier. Imagine you'd like to find a sequence of non-digits not
1599 followed by "123". You might try to write that as
1600 $_ = "ABC123";
1602 if ( /^\D*(?!123)/ ) { # Wrong!
1603 print "Yup, no 123 in $_\n";
1604 }
1605 But that isn't going to match; at least, not the way you're hoping. It
1607 claims that there is no 123 in the string. Here's a clearer picture of
1608 why that pattern matches, contrary to popular expectations:
1609 $x = 'ABC123';
1611 $y = 'ABC445';
1612 print "1: got $1\n" if $x =~ /^(ABC)(?!123)/;
1614 print "2: got $1\n" if $y =~ /^(ABC)(?!123)/;
1615 print "3: got $1\n" if $x =~ /^(\D*)(?!123)/;
1617 print "4: got $1\n" if $y =~ /^(\D*)(?!123)/;
1618 This prints
1620 2: got ABC
1622 3: got AB
1623 4: got ABC
1624 You might have expected test 3 to fail because it seems to a more
1626 general purpose version of test 1. The important difference between
1627 them is that test 3 contains a quantifier ("\D*") and so can use
1628 backtracking, whereas test 1 will not. What's happening is that you've
1629 asked "Is it true that at the start of $x, following 0 or more non-
1630 digits, you have something that's not 123?" If the pattern matcher had
1631 let "\D*" expand to "ABC", this would have caused the whole pattern to
1632 fail.
1633 The search engine will initially match "\D*" with "ABC". Then it will
1635 try to match "(?!123" with "123", which fails. But because a
1636 quantifier ("\D*") has been used in the regular expression, the search
1637 engine can backtrack and retry the match differently in the hope of
1638 matching the complete regular expression.
1639 The pattern really, really wants to succeed, so it uses the standard
1641 pattern back-off-and-retry and lets "\D*" expand to just "AB" this
1642 time. Now there's indeed something following "AB" that is not "123".
1643 It's "C123", which suffices.
1644 We can deal with this by using both an assertion and a negation. We'll
1646 say that the first part in $1 must be followed both by a digit and by
1647 something that's not "123". Remember that the look-aheads are zero-
1648 width expressions--they only look, but don't consume any of the string
1649 in their match. So rewriting this way produces what you'd expect; that
1650 is, case 5 will fail, but case 6 succeeds:
1651 print "5: got $1\n" if $x =~ /^(\D*)(?=\d)(?!123)/;
1653 print "6: got $1\n" if $y =~ /^(\D*)(?=\d)(?!123)/;
1654 6: got ABC
1656 In other words, the two zero-width assertions next to each other work
1658 as though they're ANDed together, just as you'd use any built-in
1659 assertions: "/^$/" matches only if you're at the beginning of the line
1660 AND the end of the line simultaneously. The deeper underlying truth is
1661 that juxtaposition in regular expressions always means AND, except when
1662 you write an explicit OR using the vertical bar. "/ab/" means match
1663 "a" AND (then) match "b", although the attempted matches are made at
1664 different positions because "a" is not a zero-width assertion, but a
1665 one-width assertion.
1666 WARNING: Particularly complicated regular expressions can take
1668 exponential time to solve because of the immense number of possible
1669 ways they can use backtracking to try for a match. For example,
1670 without internal optimizations done by the regular expression engine,
1671 this will take a painfully long time to run:
1672 'aaaaaaaaaaaa' =~ /((a{0,5}){0,5})*[c]/
1674 And if you used "*"'s in the internal groups instead of limiting them
1676 to 0 through 5 matches, then it would take forever--or until you ran
1677 out of stack space. Moreover, these internal optimizations are not
1678 always applicable. For example, if you put "{0,5}" instead of "*" on
1679 the external group, no current optimization is applicable, and the
1680 match takes a long time to finish.
1681 A powerful tool for optimizing such beasts is what is known as an
1683 "independent group", which does not backtrack (see "(?>pattern)").
1684 Note also that zero-length look-ahead/look-behind assertions will not
1685 backtrack to make the tail match, since they are in "logical" context:
1686 only whether they match is considered relevant. For an example where
1687 side-effects of look-ahead might have influenced the following match,
1688 see "(?>pattern)".
1689 Version 8 Regular Expressions
1691 In case you're not familiar with the "regular" Version 8 regex
1692 routines, here are the pattern-matching rules not described above.
1693 Any single character matches itself, unless it is a metacharacter with
1695 a special meaning described here or above. You can cause characters
1696 that normally function as metacharacters to be interpreted literally by
1697 prefixing them with a "\" (e.g., "\." matches a ".", not any character;
1698 "\\" matches a "\"). This escape mechanism is also required for the
1699 character used as the pattern delimiter.
1700 A series of characters matches that series of characters in the target
1702 string, so the pattern "blurfl" would match "blurfl" in the target
1703 string.
1704 You can specify a character class, by enclosing a list of characters in
1706 "[]", which will match any character from the list. If the first
1707 character after the "[" is "^", the class matches any character not in
1708 the list. Within a list, the "-" character specifies a range, so that
1709 "a-z" represents all characters between "a" and "z", inclusive. If you
1710 want either "-" or "]" itself to be a member of a class, put it at the
1711 start of the list (possibly after a "^"), or escape it with a
1712 backslash. "-" is also taken literally when it is at the end of the
1713 list, just before the closing "]". (The following all specify the same
1714 class of three characters: "[-az]", "[az-]", and "[a\-z]". All are
1715 different from "[a-z]", which specifies a class containing twenty-six
1716 characters, even on EBCDIC-based character sets.) Also, if you try to
1717 use the character classes "\w", "\W", "\s", "\S", "\d", or "\D" as
1718 endpoints of a range, the "-" is understood literally.
1719 Note also that the whole range idea is rather unportable between
1721 character sets--and even within character sets they may cause results
1722 you probably didn't expect. A sound principle is to use only ranges
1723 that begin from and end at either alphabetics of equal case ([a-e],
1724 [A-E]), or digits ([0-9]). Anything else is unsafe. If in doubt,
1725 spell out the character sets in full.
1726 Characters may be specified using a metacharacter syntax much like that
1728 used in C: "\n" matches a newline, "\t" a tab, "\r" a carriage return,
1729 "\f" a form feed, etc. More generally, \nnn, where nnn is a string of
1730 octal digits, matches the character whose coded character set value is
1731 nnn. Similarly, \xnn, where nn are hexadecimal digits, matches the
1732 character whose numeric value is nn. The expression \cx matches the
1733 character control-x. Finally, the "." metacharacter matches any
1734 character except "\n" (unless you use "/s").
1735 You can specify a series of alternatives for a pattern using "|" to
1737 separate them, so that "fee|fie|foe" will match any of "fee", "fie", or
1738 "foe" in the target string (as would "f(e|i|o)e"). The first
1739 alternative includes everything from the last pattern delimiter ("(",
1740 "[", or the beginning of the pattern) up to the first "|", and the last
1741 alternative contains everything from the last "|" to the next pattern
1742 delimiter. That's why it's common practice to include alternatives in
1743 parentheses: to minimize confusion about where they start and end.
1744 Alternatives are tried from left to right, so the first alternative
1746 found for which the entire expression matches, is the one that is
1747 chosen. This means that alternatives are not necessarily greedy. For
1748 example: when matching "foo|foot" against "barefoot", only the "foo"
1749 part will match, as that is the first alternative tried, and it
1750 successfully matches the target string. (This might not seem important,
1751 but it is important when you are capturing matched text using
1752 parentheses.)
1753 Also remember that "|" is interpreted as a literal within square
1755 brackets, so if you write "[fee|fie|foe]" you're really only matching
1756 "[feio|]".
1757 Within a pattern, you may designate subpatterns for later reference by
1759 enclosing them in parentheses, and you may refer back to the nth
1760 subpattern later in the pattern using the metacharacter \n.
1761 Subpatterns are numbered based on the left to right order of their
1762 opening parenthesis. A backreference matches whatever actually matched
1763 the subpattern in the string being examined, not the rules for that
1764 subpattern. Therefore, "(0|0x)\d*\s\1\d*" will match "0x1234 0x4321",
1765 but not "0x1234 01234", because subpattern 1 matched "0x", even though
1766 the rule "0|0x" could potentially match the leading 0 in the second
1767 number.
1768 Warning on \1 Instead of $1
1770 Some people get too used to writing things like:
1771 $pattern =~ s/(\W)/\\\1/g;
1773 This is grandfathered for the RHS of a substitute to avoid shocking the
1775 sed addicts, but it's a dirty habit to get into. That's because in
1776 PerlThink, the righthand side of an "s///" is a double-quoted string.
1777 "\1" in the usual double-quoted string means a control-A. The
1778 customary Unix meaning of "\1" is kludged in for "s///". However, if
1779 you get into the habit of doing that, you get yourself into trouble if
1780 you then add an "/e" modifier.
1781 s/(\d+)/ \1 + 1 /eg; # causes warning under -w
1783 Or if you try to do
1785 s/(\d+)/\1000/;
1787 You can't disambiguate that by saying "\{1}000", whereas you can fix it
1789 with "${1}000". The operation of interpolation should not be confused
1790 with the operation of matching a backreference. Certainly they mean
1791 two different things on the left side of the "s///".
1792 Repeated Patterns Matching a Zero-length Substring
1794 WARNING: Difficult material (and prose) ahead. This section needs a
1795 rewrite.
1796 Regular expressions provide a terse and powerful programming language.
1798 As with most other power tools, power comes together with the ability
1799 to wreak havoc.
1800 A common abuse of this power stems from the ability to make infinite
1802 loops using regular expressions, with something as innocuous as:
1803 'foo' =~ m{ ( o? )* }x;
1805 The "o?" matches at the beginning of 'foo', and since the position in
1807 the string is not moved by the match, "o?" would match again and again
1808 because of the "*" quantifier. Another common way to create a similar
1809 cycle is with the looping modifier "//g":
1810 @matches = ( 'foo' =~ m{ o? }xg );
1812 or
1814 print "match: <$&>\n" while 'foo' =~ m{ o? }xg;
1816 or the loop implied by split().
1818 However, long experience has shown that many programming tasks may be
1820 significantly simplified by using repeated subexpressions that may
1821 match zero-length substrings. Here's a simple example being:
1822 @chars = split //, $string; # // is not magic in split
1824 ($whitewashed = $string) =~ s/()/ /g; # parens avoid magic s// /
1825 Thus Perl allows such constructs, by forcefully breaking the infinite
1827 loop. The rules for this are different for lower-level loops given by
1828 the greedy quantifiers "*+{}", and for higher-level ones like the "/g"
1829 modifier or split() operator.
1830 The lower-level loops are interrupted (that is, the loop is broken)
1832 when Perl detects that a repeated expression matched a zero-length
1833 substring. Thus
1834 m{ (?: NON_ZERO_LENGTH | ZERO_LENGTH )* }x;
1836 is made equivalent to
1838 m{ (?: NON_ZERO_LENGTH )*
1840 |
1841 (?: ZERO_LENGTH )?
1842 }x;
1843 The higher level-loops preserve an additional state between iterations:
1845 whether the last match was zero-length. To break the loop, the
1846 following match after a zero-length match is prohibited to have a
1847 length of zero. This prohibition interacts with backtracking (see
1848 "Backtracking"), and so the second best match is chosen if the best
1849 match is of zero length.
1850 For example:
1852 $_ = 'bar';
1854 s/\w??/<$&>/g;
1855 results in "<><b><><a><><r><>". At each position of the string the
1857 best match given by non-greedy "??" is the zero-length match, and the
1858 second best match is what is matched by "\w". Thus zero-length matches
1859 alternate with one-character-long matches.
1860 Similarly, for repeated "m/()/g" the second-best match is the match at
1862 the position one notch further in the string.
1863 The additional state of being matched with zero-length is associated
1865 with the matched string, and is reset by each assignment to pos().
1866 Zero-length matches at the end of the previous match are ignored during
1867 "split".
1868 Combining RE Pieces
1870 Each of the elementary pieces of regular expressions which were
1871 described before (such as "ab" or "\Z") could match at most one
1872 substring at the given position of the input string. However, in a
1873 typical regular expression these elementary pieces are combined into
1874 more complicated patterns using combining operators "ST", "S|T", "S*"
1875 etc (in these examples "S" and "T" are regular subexpressions).
1876 Such combinations can include alternatives, leading to a problem of
1878 choice: if we match a regular expression "a|ab" against "abc", will it
1879 match substring "a" or "ab"? One way to describe which substring is
1880 actually matched is the concept of backtracking (see "Backtracking").
1881 However, this description is too low-level and makes you think in terms
1882 of a particular implementation.
1883 Another description starts with notions of "better"/"worse". All the
1885 substrings which may be matched by the given regular expression can be
1886 sorted from the "best" match to the "worst" match, and it is the "best"
1887 match which is chosen. This substitutes the question of "what is
1888 chosen?" by the question of "which matches are better, and which are
1889 worse?".
1890 Again, for elementary pieces there is no such question, since at most
1892 one match at a given position is possible. This section describes the
1893 notion of better/worse for combining operators. In the description
1894 below "S" and "T" are regular subexpressions.
1895 "ST"
1897 Consider two possible matches, "AB" and "A'B'", "A" and "A'" are
1898 substrings which can be matched by "S", "B" and "B'" are substrings
1899 which can be matched by "T".
1900 If "A" is better match for "S" than "A'", "AB" is a better match
1902 than "A'B'".
1903 If "A" and "A'" coincide: "AB" is a better match than "AB'" if "B"
1905 is better match for "T" than "B'".
1906 "S|T"
1908 When "S" can match, it is a better match than when only "T" can
1909 match.
1910 Ordering of two matches for "S" is the same as for "S". Similar
1912 for two matches for "T".
1913 "S{REPEAT_COUNT}"
1915 Matches as "SSS...S" (repeated as many times as necessary).
1916 "S{min,max}"
1918 Matches as "S{max}|S{max-1}|...|S{min+1}|S{min}".
1919 "S{min,max}?"
1921 Matches as "S{min}|S{min+1}|...|S{max-1}|S{max}".
1922 "S?", "S*", "S+"
1924 Same as "S{0,1}", "S{0,BIG_NUMBER}", "S{1,BIG_NUMBER}"
1925 respectively.
1926 "S??", "S*?", "S+?"
1928 Same as "S{0,1}?", "S{0,BIG_NUMBER}?", "S{1,BIG_NUMBER}?"
1929 respectively.
1930 "(?>S)"
1932 Matches the best match for "S" and only that.
1933 "(?=S)", "(?<=S)"
1935 Only the best match for "S" is considered. (This is important only
1936 if "S" has capturing parentheses, and backreferences are used
1937 somewhere else in the whole regular expression.)
1938 "(?!S)", "(?<!S)"
1940 For this grouping operator there is no need to describe the
1941 ordering, since only whether or not "S" can match is important.
1942 "(??{ EXPR })", "(?PARNO)"
1944 The ordering is the same as for the regular expression which is the
1945 result of EXPR, or the pattern contained by capture buffer PARNO.
1946 "(?(condition)yes-pattern|no-pattern)"
1948 Recall that which of "yes-pattern" or "no-pattern" actually matches
1949 is already determined. The ordering of the matches is the same as
1950 for the chosen subexpression.
1951 The above recipes describe the ordering of matches at a given position.
1953 One more rule is needed to understand how a match is determined for the
1954 whole regular expression: a match at an earlier position is always
1955 better than a match at a later position.
1956 Creating Custom RE Engines
1958 Overloaded constants (see overload) provide a simple way to extend the
1959 functionality of the RE engine.
1960 Suppose that we want to enable a new RE escape-sequence "\Y|" which
1962 matches at a boundary between whitespace characters and non-whitespace
1963 characters. Note that "(?=\S)(?<!\S)|(?!\S)(?<=\S)" matches exactly at
1964 these positions, so we want to have each "\Y|" in the place of the more
1965 complicated version. We can create a module "customre" to do this:
1966 package customre;
1968 use overload;
1969 sub import {
1971 shift;
1972 die "No argument to customre::import allowed" if @_;
1973 overload::constant 'qr' => \&convert;
1974 }
1975 sub invalid { die "/$_[0]/: invalid escape '\\$_[1]'"}
1977 # We must also take care of not escaping the legitimate \\Y|
1979 # sequence, hence the presence of '\\' in the conversion rules.
1980 my %rules = ( '\\' => '\\\\',
1981 'Y|' => qr/(?=\S)(?<!\S)|(?!\S)(?<=\S)/ );
1982 sub convert {
1983 my $re = shift;
1984 $re =~ s{
1985 \\ ( \\ | Y . )
1986 }
1987 { $rules{$1} or invalid($re,$1) }sgex;
1988 return $re;
1989 }
1990 Now "use customre" enables the new escape in constant regular
1992 expressions, i.e., those without any runtime variable interpolations.
1993 As documented in overload, this conversion will work only over literal
1994 parts of regular expressions. For "\Y|$re\Y|" the variable part of
1995 this regular expression needs to be converted explicitly (but only if
1996 the special meaning of "\Y|" should be enabled inside $re):
1997 use customre;
1999 $re = <>;
2000 chomp $re;
2001 $re = customre::convert $re;
2002 /\Y|$re\Y|/;
2003
2005 As of Perl 5.10.0, Perl supports several Python/PCRE specific
2006 extensions to the regex syntax. While Perl programmers are encouraged
2007 to use the Perl specific syntax, the following are also accepted:
2008 "(?PE<lt>NAMEE<gt>pattern)"
2010 Define a named capture buffer. Equivalent to "(?<NAME>pattern)".
2011 "(?P=NAME)"
2013 Backreference to a named capture buffer. Equivalent to "\g{NAME}".
2014 "(?P>NAME)"
2016 Subroutine call to a named capture buffer. Equivalent to
2017 "(?&NAME)".
2018
2020 This document varies from difficult to understand to completely and
2021 utterly opaque. The wandering prose riddled with jargon is hard to
2022 fathom in several places.
2023 This document needs a rewrite that separates the tutorial content from
2025 the reference content.
2026
2028 perlrequick.
2029 perlretut.
2031 "Regexp Quote-Like Operators" in perlop.
2033 "Gory details of parsing quoted constructs" in perlop.
2035 perlfaq6.
2037 "pos" in perlfunc.
2039 perllocale.
2041 perlebcdic.
2043 Mastering Regular Expressions by Jeffrey Friedl, published by O'Reilly
2045 and Associates.
2046perl v5.10.1 2009-02-12 PERLRE(1)