1 | =head1 NAME
|
---|
2 | X<regular expression> X<regex> X<regexp>
|
---|
3 |
|
---|
4 | perlre - Perl regular expressions
|
---|
5 |
|
---|
6 | =head1 DESCRIPTION
|
---|
7 |
|
---|
8 | This page describes the syntax of regular expressions in Perl.
|
---|
9 |
|
---|
10 | If you haven't used regular expressions before, a quick-start
|
---|
11 | introduction is available in L<perlrequick>, and a longer tutorial
|
---|
12 | introduction is available in L<perlretut>.
|
---|
13 |
|
---|
14 | For reference on how regular expressions are used in matching
|
---|
15 | operations, plus various examples of the same, see discussions of
|
---|
16 | C<m//>, C<s///>, C<qr//> and C<??> in L<perlop/"Regexp Quote-Like
|
---|
17 | Operators">.
|
---|
18 |
|
---|
19 | Matching operations can have various modifiers. Modifiers
|
---|
20 | that relate to the interpretation of the regular expression inside
|
---|
21 | are listed below. Modifiers that alter the way a regular expression
|
---|
22 | is used by Perl are detailed in L<perlop/"Regexp Quote-Like Operators"> and
|
---|
23 | L<perlop/"Gory details of parsing quoted constructs">.
|
---|
24 |
|
---|
25 | =over 4
|
---|
26 |
|
---|
27 | =item i
|
---|
28 | X</i> X<regex, case-insensitive> X<regexp, case-insensitive>
|
---|
29 | X<regular expression, case-insensitive>
|
---|
30 |
|
---|
31 | Do case-insensitive pattern matching.
|
---|
32 |
|
---|
33 | If C<use locale> is in effect, the case map is taken from the current
|
---|
34 | locale. See L<perllocale>.
|
---|
35 |
|
---|
36 | =item m
|
---|
37 | X</m> X<regex, multiline> X<regexp, multiline> X<regular expression, multiline>
|
---|
38 |
|
---|
39 | Treat string as multiple lines. That is, change "^" and "$" from matching
|
---|
40 | the start or end of the string to matching the start or end of any
|
---|
41 | line anywhere within the string.
|
---|
42 |
|
---|
43 | =item s
|
---|
44 | X</s> X<regex, single-line> X<regexp, single-line>
|
---|
45 | X<regular expression, single-line>
|
---|
46 |
|
---|
47 | Treat string as single line. That is, change "." to match any character
|
---|
48 | whatsoever, even a newline, which normally it would not match.
|
---|
49 |
|
---|
50 | The C</s> and C</m> modifiers both override the C<$*> setting. That
|
---|
51 | is, no matter what C<$*> contains, C</s> without C</m> will force
|
---|
52 | "^" to match only at the beginning of the string and "$" to match
|
---|
53 | only at the end (or just before a newline at the end) of the string.
|
---|
54 | Together, as /ms, they let the "." match any character whatsoever,
|
---|
55 | while still allowing "^" and "$" to match, respectively, just after
|
---|
56 | and just before newlines within the string.
|
---|
57 |
|
---|
58 | =item x
|
---|
59 | X</x>
|
---|
60 |
|
---|
61 | Extend your pattern's legibility by permitting whitespace and comments.
|
---|
62 |
|
---|
63 | =back
|
---|
64 |
|
---|
65 | These are usually written as "the C</x> modifier", even though the delimiter
|
---|
66 | in question might not really be a slash. Any of these
|
---|
67 | modifiers may also be embedded within the regular expression itself using
|
---|
68 | the C<(?...)> construct. See below.
|
---|
69 |
|
---|
70 | The C</x> modifier itself needs a little more explanation. It tells
|
---|
71 | the regular expression parser to ignore whitespace that is neither
|
---|
72 | backslashed nor within a character class. You can use this to break up
|
---|
73 | your regular expression into (slightly) more readable parts. The C<#>
|
---|
74 | character is also treated as a metacharacter introducing a comment,
|
---|
75 | just as in ordinary Perl code. This also means that if you want real
|
---|
76 | whitespace or C<#> characters in the pattern (outside a character
|
---|
77 | class, where they are unaffected by C</x>), that you'll either have to
|
---|
78 | escape them or encode them using octal or hex escapes. Taken together,
|
---|
79 | these features go a long way towards making Perl's regular expressions
|
---|
80 | more readable. Note that you have to be careful not to include the
|
---|
81 | pattern delimiter in the comment--perl has no way of knowing you did
|
---|
82 | not intend to close the pattern early. See the C-comment deletion code
|
---|
83 | in L<perlop>.
|
---|
84 | X</x>
|
---|
85 |
|
---|
86 | =head2 Regular Expressions
|
---|
87 |
|
---|
88 | The patterns used in Perl pattern matching derive from supplied in
|
---|
89 | the Version 8 regex routines. (The routines are derived
|
---|
90 | (distantly) from Henry Spencer's freely redistributable reimplementation
|
---|
91 | of the V8 routines.) See L<Version 8 Regular Expressions> for
|
---|
92 | details.
|
---|
93 |
|
---|
94 | In particular the following metacharacters have their standard I<egrep>-ish
|
---|
95 | meanings:
|
---|
96 | X<metacharacter>
|
---|
97 | X<\> X<^> X<.> X<$> X<|> X<(> X<()> X<[> X<[]>
|
---|
98 |
|
---|
99 |
|
---|
100 | \ Quote the next metacharacter
|
---|
101 | ^ Match the beginning of the line
|
---|
102 | . Match any character (except newline)
|
---|
103 | $ Match the end of the line (or before newline at the end)
|
---|
104 | | Alternation
|
---|
105 | () Grouping
|
---|
106 | [] Character class
|
---|
107 |
|
---|
108 | By default, the "^" character is guaranteed to match only the
|
---|
109 | beginning of the string, the "$" character only the end (or before the
|
---|
110 | newline at the end), and Perl does certain optimizations with the
|
---|
111 | assumption that the string contains only one line. Embedded newlines
|
---|
112 | will not be matched by "^" or "$". You may, however, wish to treat a
|
---|
113 | string as a multi-line buffer, such that the "^" will match after any
|
---|
114 | newline within the string, and "$" will match before any newline. At the
|
---|
115 | cost of a little more overhead, you can do this by using the /m modifier
|
---|
116 | on the pattern match operator. (Older programs did this by setting C<$*>,
|
---|
117 | but this practice is now deprecated.)
|
---|
118 | X<^> X<$> X</m>
|
---|
119 |
|
---|
120 | To simplify multi-line substitutions, the "." character never matches a
|
---|
121 | newline unless you use the C</s> modifier, which in effect tells Perl to pretend
|
---|
122 | the string is a single line--even if it isn't. The C</s> modifier also
|
---|
123 | overrides the setting of C<$*>, in case you have some (badly behaved) older
|
---|
124 | code that sets it in another module.
|
---|
125 | X<.> X</s>
|
---|
126 |
|
---|
127 | The following standard quantifiers are recognized:
|
---|
128 | X<metacharacter> X<quantifier> X<*> X<+> X<?> X<{n}> X<{n,}> X<{n,m}>
|
---|
129 |
|
---|
130 | * Match 0 or more times
|
---|
131 | + Match 1 or more times
|
---|
132 | ? Match 1 or 0 times
|
---|
133 | {n} Match exactly n times
|
---|
134 | {n,} Match at least n times
|
---|
135 | {n,m} Match at least n but not more than m times
|
---|
136 |
|
---|
137 | (If a curly bracket occurs in any other context, it is treated
|
---|
138 | as a regular character. In particular, the lower bound
|
---|
139 | is not optional.) The "*" modifier is equivalent to C<{0,}>, the "+"
|
---|
140 | modifier to C<{1,}>, and the "?" modifier to C<{0,1}>. n and m are limited
|
---|
141 | to integral values less than a preset limit defined when perl is built.
|
---|
142 | This is usually 32766 on the most common platforms. The actual limit can
|
---|
143 | be seen in the error message generated by code such as this:
|
---|
144 |
|
---|
145 | $_ **= $_ , / {$_} / for 2 .. 42;
|
---|
146 |
|
---|
147 | By default, a quantified subpattern is "greedy", that is, it will match as
|
---|
148 | many times as possible (given a particular starting location) while still
|
---|
149 | allowing the rest of the pattern to match. If you want it to match the
|
---|
150 | minimum number of times possible, follow the quantifier with a "?". Note
|
---|
151 | that the meanings don't change, just the "greediness":
|
---|
152 | X<metacharacter> X<greedy> X<greedyness>
|
---|
153 | X<?> X<*?> X<+?> X<??> X<{n}?> X<{n,}?> X<{n,m}?>
|
---|
154 |
|
---|
155 | *? Match 0 or more times
|
---|
156 | +? Match 1 or more times
|
---|
157 | ?? Match 0 or 1 time
|
---|
158 | {n}? Match exactly n times
|
---|
159 | {n,}? Match at least n times
|
---|
160 | {n,m}? Match at least n but not more than m times
|
---|
161 |
|
---|
162 | Because patterns are processed as double quoted strings, the following
|
---|
163 | also work:
|
---|
164 | X<\t> X<\n> X<\r> X<\f> X<\a> X<\l> X<\u> X<\L> X<\U> X<\E> X<\Q>
|
---|
165 | X<\0> X<\c> X<\N> X<\x>
|
---|
166 |
|
---|
167 | \t tab (HT, TAB)
|
---|
168 | \n newline (LF, NL)
|
---|
169 | \r return (CR)
|
---|
170 | \f form feed (FF)
|
---|
171 | \a alarm (bell) (BEL)
|
---|
172 | \e escape (think troff) (ESC)
|
---|
173 | \033 octal char (think of a PDP-11)
|
---|
174 | \x1B hex char
|
---|
175 | \x{263a} wide hex char (Unicode SMILEY)
|
---|
176 | \c[ control char
|
---|
177 | \N{name} named char
|
---|
178 | \l lowercase next char (think vi)
|
---|
179 | \u uppercase next char (think vi)
|
---|
180 | \L lowercase till \E (think vi)
|
---|
181 | \U uppercase till \E (think vi)
|
---|
182 | \E end case modification (think vi)
|
---|
183 | \Q quote (disable) pattern metacharacters till \E
|
---|
184 |
|
---|
185 | If C<use locale> is in effect, the case map used by C<\l>, C<\L>, C<\u>
|
---|
186 | and C<\U> is taken from the current locale. See L<perllocale>. For
|
---|
187 | documentation of C<\N{name}>, see L<charnames>.
|
---|
188 |
|
---|
189 | You cannot include a literal C<$> or C<@> within a C<\Q> sequence.
|
---|
190 | An unescaped C<$> or C<@> interpolates the corresponding variable,
|
---|
191 | while escaping will cause the literal string C<\$> to be matched.
|
---|
192 | You'll need to write something like C<m/\Quser\E\@\Qhost/>.
|
---|
193 |
|
---|
194 | In addition, Perl defines the following:
|
---|
195 | X<metacharacter>
|
---|
196 | X<\w> X<\W> X<\s> X<\S> X<\d> X<\D> X<\X> X<\p> X<\P> X<\C>
|
---|
197 | X<word> X<whitespace>
|
---|
198 |
|
---|
199 | \w Match a "word" character (alphanumeric plus "_")
|
---|
200 | \W Match a non-"word" character
|
---|
201 | \s Match a whitespace character
|
---|
202 | \S Match a non-whitespace character
|
---|
203 | \d Match a digit character
|
---|
204 | \D Match a non-digit character
|
---|
205 | \pP Match P, named property. Use \p{Prop} for longer names.
|
---|
206 | \PP Match non-P
|
---|
207 | \X Match eXtended Unicode "combining character sequence",
|
---|
208 | equivalent to (?:\PM\pM*)
|
---|
209 | \C Match a single C char (octet) even under Unicode.
|
---|
210 | NOTE: breaks up characters into their UTF-8 bytes,
|
---|
211 | so you may end up with malformed pieces of UTF-8.
|
---|
212 | Unsupported in lookbehind.
|
---|
213 |
|
---|
214 | A C<\w> matches a single alphanumeric character (an alphabetic
|
---|
215 | character, or a decimal digit) or C<_>, not a whole word. Use C<\w+>
|
---|
216 | to match a string of Perl-identifier characters (which isn't the same
|
---|
217 | as matching an English word). If C<use locale> is in effect, the list
|
---|
218 | of alphabetic characters generated by C<\w> is taken from the current
|
---|
219 | locale. See L<perllocale>. You may use C<\w>, C<\W>, C<\s>, C<\S>,
|
---|
220 | C<\d>, and C<\D> within character classes, but if you try to use them
|
---|
221 | as endpoints of a range, that's not a range, the "-" is understood
|
---|
222 | literally. If Unicode is in effect, C<\s> matches also "\x{85}",
|
---|
223 | "\x{2028}, and "\x{2029}", see L<perlunicode> for more details about
|
---|
224 | C<\pP>, C<\PP>, and C<\X>, and L<perluniintro> about Unicode in general.
|
---|
225 | You can define your own C<\p> and C<\P> properties, see L<perlunicode>.
|
---|
226 | X<\w> X<\W> X<word>
|
---|
227 |
|
---|
228 | The POSIX character class syntax
|
---|
229 | X<character class>
|
---|
230 |
|
---|
231 | [:class:]
|
---|
232 |
|
---|
233 | is also available. The available classes and their backslash
|
---|
234 | equivalents (if available) are as follows:
|
---|
235 | X<character class>
|
---|
236 | X<alpha> X<alnum> X<ascii> X<blank> X<cntrl> X<digit> X<graph>
|
---|
237 | X<lower> X<print> X<punct> X<space> X<upper> X<word> X<xdigit>
|
---|
238 |
|
---|
239 | alpha
|
---|
240 | alnum
|
---|
241 | ascii
|
---|
242 | blank [1]
|
---|
243 | cntrl
|
---|
244 | digit \d
|
---|
245 | graph
|
---|
246 | lower
|
---|
247 | print
|
---|
248 | punct
|
---|
249 | space \s [2]
|
---|
250 | upper
|
---|
251 | word \w [3]
|
---|
252 | xdigit
|
---|
253 |
|
---|
254 | =over
|
---|
255 |
|
---|
256 | =item [1]
|
---|
257 |
|
---|
258 | A GNU extension equivalent to C<[ \t]>, "all horizontal whitespace".
|
---|
259 |
|
---|
260 | =item [2]
|
---|
261 |
|
---|
262 | Not exactly equivalent to C<\s> since the C<[[:space:]]> includes
|
---|
263 | also the (very rare) "vertical tabulator", "\ck", chr(11).
|
---|
264 |
|
---|
265 | =item [3]
|
---|
266 |
|
---|
267 | A Perl extension, see above.
|
---|
268 |
|
---|
269 | =back
|
---|
270 |
|
---|
271 | For example use C<[:upper:]> to match all the uppercase characters.
|
---|
272 | Note that the C<[]> are part of the C<[::]> construct, not part of the
|
---|
273 | whole character class. For example:
|
---|
274 |
|
---|
275 | [01[:alpha:]%]
|
---|
276 |
|
---|
277 | matches zero, one, any alphabetic character, and the percentage sign.
|
---|
278 |
|
---|
279 | The following equivalences to Unicode \p{} constructs and equivalent
|
---|
280 | backslash character classes (if available), will hold:
|
---|
281 | X<character class> X<\p> X<\p{}>
|
---|
282 |
|
---|
283 | [:...:] \p{...} backslash
|
---|
284 |
|
---|
285 | alpha IsAlpha
|
---|
286 | alnum IsAlnum
|
---|
287 | ascii IsASCII
|
---|
288 | blank IsSpace
|
---|
289 | cntrl IsCntrl
|
---|
290 | digit IsDigit \d
|
---|
291 | graph IsGraph
|
---|
292 | lower IsLower
|
---|
293 | print IsPrint
|
---|
294 | punct IsPunct
|
---|
295 | space IsSpace
|
---|
296 | IsSpacePerl \s
|
---|
297 | upper IsUpper
|
---|
298 | word IsWord
|
---|
299 | xdigit IsXDigit
|
---|
300 |
|
---|
301 | For example C<[:lower:]> and C<\p{IsLower}> are equivalent.
|
---|
302 |
|
---|
303 | If the C<utf8> pragma is not used but the C<locale> pragma is, the
|
---|
304 | classes correlate with the usual isalpha(3) interface (except for
|
---|
305 | "word" and "blank").
|
---|
306 |
|
---|
307 | The assumedly non-obviously named classes are:
|
---|
308 |
|
---|
309 | =over 4
|
---|
310 |
|
---|
311 | =item cntrl
|
---|
312 | X<cntrl>
|
---|
313 |
|
---|
314 | Any control character. Usually characters that don't produce output as
|
---|
315 | such but instead control the terminal somehow: for example newline and
|
---|
316 | backspace are control characters. All characters with ord() less than
|
---|
317 | 32 are most often classified as control characters (assuming ASCII,
|
---|
318 | the ISO Latin character sets, and Unicode), as is the character with
|
---|
319 | the ord() value of 127 (C<DEL>).
|
---|
320 |
|
---|
321 | =item graph
|
---|
322 | X<graph>
|
---|
323 |
|
---|
324 | Any alphanumeric or punctuation (special) character.
|
---|
325 |
|
---|
326 | =item print
|
---|
327 | X<print>
|
---|
328 |
|
---|
329 | Any alphanumeric or punctuation (special) character or the space character.
|
---|
330 |
|
---|
331 | =item punct
|
---|
332 | X<punct>
|
---|
333 |
|
---|
334 | Any punctuation (special) character.
|
---|
335 |
|
---|
336 | =item xdigit
|
---|
337 | X<xdigit>
|
---|
338 |
|
---|
339 | Any hexadecimal digit. Though this may feel silly ([0-9A-Fa-f] would
|
---|
340 | work just fine) it is included for completeness.
|
---|
341 |
|
---|
342 | =back
|
---|
343 |
|
---|
344 | You can negate the [::] character classes by prefixing the class name
|
---|
345 | with a '^'. This is a Perl extension. For example:
|
---|
346 | X<character class, negation>
|
---|
347 |
|
---|
348 | POSIX traditional Unicode
|
---|
349 |
|
---|
350 | [:^digit:] \D \P{IsDigit}
|
---|
351 | [:^space:] \S \P{IsSpace}
|
---|
352 | [:^word:] \W \P{IsWord}
|
---|
353 |
|
---|
354 | Perl respects the POSIX standard in that POSIX character classes are
|
---|
355 | only supported within a character class. The POSIX character classes
|
---|
356 | [.cc.] and [=cc=] are recognized but B<not> supported and trying to
|
---|
357 | use them will cause an error.
|
---|
358 |
|
---|
359 | Perl defines the following zero-width assertions:
|
---|
360 | X<zero-width assertion> X<assertion> X<regex, zero-width assertion>
|
---|
361 | X<regexp, zero-width assertion>
|
---|
362 | X<regular expression, zero-width assertion>
|
---|
363 | X<\b> X<\B> X<\A> X<\Z> X<\z> X<\G>
|
---|
364 |
|
---|
365 | \b Match a word boundary
|
---|
366 | \B Match a non-(word boundary)
|
---|
367 | \A Match only at beginning of string
|
---|
368 | \Z Match only at end of string, or before newline at the end
|
---|
369 | \z Match only at end of string
|
---|
370 | \G Match only at pos() (e.g. at the end-of-match position
|
---|
371 | of prior m//g)
|
---|
372 |
|
---|
373 | A word boundary (C<\b>) is a spot between two characters
|
---|
374 | that has a C<\w> on one side of it and a C<\W> on the other side
|
---|
375 | of it (in either order), counting the imaginary characters off the
|
---|
376 | beginning and end of the string as matching a C<\W>. (Within
|
---|
377 | character classes C<\b> represents backspace rather than a word
|
---|
378 | boundary, just as it normally does in any double-quoted string.)
|
---|
379 | The C<\A> and C<\Z> are just like "^" and "$", except that they
|
---|
380 | won't match multiple times when the C</m> modifier is used, while
|
---|
381 | "^" and "$" will match at every internal line boundary. To match
|
---|
382 | the actual end of the string and not ignore an optional trailing
|
---|
383 | newline, use C<\z>.
|
---|
384 | X<\b> X<\A> X<\Z> X<\z> X</m>
|
---|
385 |
|
---|
386 | The C<\G> assertion can be used to chain global matches (using
|
---|
387 | C<m//g>), as described in L<perlop/"Regexp Quote-Like Operators">.
|
---|
388 | It is also useful when writing C<lex>-like scanners, when you have
|
---|
389 | several patterns that you want to match against consequent substrings
|
---|
390 | of your string, see the previous reference. The actual location
|
---|
391 | where C<\G> will match can also be influenced by using C<pos()> as
|
---|
392 | an lvalue: see L<perlfunc/pos>. Currently C<\G> is only fully
|
---|
393 | supported when anchored to the start of the pattern; while it
|
---|
394 | is permitted to use it elsewhere, as in C</(?<=\G..)./g>, some
|
---|
395 | such uses (C</.\G/g>, for example) currently cause problems, and
|
---|
396 | it is recommended that you avoid such usage for now.
|
---|
397 | X<\G>
|
---|
398 |
|
---|
399 | The bracketing construct C<( ... )> creates capture buffers. To
|
---|
400 | refer to the digit'th buffer use \<digit> within the
|
---|
401 | match. Outside the match use "$" instead of "\". (The
|
---|
402 | \<digit> notation works in certain circumstances outside
|
---|
403 | the match. See the warning below about \1 vs $1 for details.)
|
---|
404 | Referring back to another part of the match is called a
|
---|
405 | I<backreference>.
|
---|
406 | X<regex, capture buffer> X<regexp, capture buffer>
|
---|
407 | X<regular expression, capture buffer> X<backreference>
|
---|
408 |
|
---|
409 | There is no limit to the number of captured substrings that you may
|
---|
410 | use. However Perl also uses \10, \11, etc. as aliases for \010,
|
---|
411 | \011, etc. (Recall that 0 means octal, so \011 is the character at
|
---|
412 | number 9 in your coded character set; which would be the 10th character,
|
---|
413 | a horizontal tab under ASCII.) Perl resolves this
|
---|
414 | ambiguity by interpreting \10 as a backreference only if at least 10
|
---|
415 | left parentheses have opened before it. Likewise \11 is a
|
---|
416 | backreference only if at least 11 left parentheses have opened
|
---|
417 | before it. And so on. \1 through \9 are always interpreted as
|
---|
418 | backreferences.
|
---|
419 |
|
---|
420 | Examples:
|
---|
421 |
|
---|
422 | s/^([^ ]*) *([^ ]*)/$2 $1/; # swap first two words
|
---|
423 |
|
---|
424 | if (/(.)\1/) { # find first doubled char
|
---|
425 | print "'$1' is the first doubled character\n";
|
---|
426 | }
|
---|
427 |
|
---|
428 | if (/Time: (..):(..):(..)/) { # parse out values
|
---|
429 | $hours = $1;
|
---|
430 | $minutes = $2;
|
---|
431 | $seconds = $3;
|
---|
432 | }
|
---|
433 |
|
---|
434 | Several special variables also refer back to portions of the previous
|
---|
435 | match. C<$+> returns whatever the last bracket match matched.
|
---|
436 | C<$&> returns the entire matched string. (At one point C<$0> did
|
---|
437 | also, but now it returns the name of the program.) C<$`> returns
|
---|
438 | everything before the matched string. C<$'> returns everything
|
---|
439 | after the matched string. And C<$^N> contains whatever was matched by
|
---|
440 | the most-recently closed group (submatch). C<$^N> can be used in
|
---|
441 | extended patterns (see below), for example to assign a submatch to a
|
---|
442 | variable.
|
---|
443 | X<$+> X<$^N> X<$&> X<$`> X<$'>
|
---|
444 |
|
---|
445 | The numbered match variables ($1, $2, $3, etc.) and the related punctuation
|
---|
446 | set (C<$+>, C<$&>, C<$`>, C<$'>, and C<$^N>) are all dynamically scoped
|
---|
447 | until the end of the enclosing block or until the next successful
|
---|
448 | match, whichever comes first. (See L<perlsyn/"Compound Statements">.)
|
---|
449 | X<$+> X<$^N> X<$&> X<$`> X<$'>
|
---|
450 | X<$1> X<$2> X<$3> X<$4> X<$5> X<$6> X<$7> X<$8> X<$9>
|
---|
451 |
|
---|
452 |
|
---|
453 | B<NOTE>: failed matches in Perl do not reset the match variables,
|
---|
454 | which makes it easier to write code that tests for a series of more
|
---|
455 | specific cases and remembers the best match.
|
---|
456 |
|
---|
457 | B<WARNING>: Once Perl sees that you need one of C<$&>, C<$`>, or
|
---|
458 | C<$'> anywhere in the program, it has to provide them for every
|
---|
459 | pattern match. This may substantially slow your program. Perl
|
---|
460 | uses the same mechanism to produce $1, $2, etc, so you also pay a
|
---|
461 | price for each pattern that contains capturing parentheses. (To
|
---|
462 | avoid this cost while retaining the grouping behaviour, use the
|
---|
463 | extended regular expression C<(?: ... )> instead.) But if you never
|
---|
464 | use C<$&>, C<$`> or C<$'>, then patterns I<without> capturing
|
---|
465 | parentheses will not be penalized. So avoid C<$&>, C<$'>, and C<$`>
|
---|
466 | if you can, but if you can't (and some algorithms really appreciate
|
---|
467 | them), once you've used them once, use them at will, because you've
|
---|
468 | already paid the price. As of 5.005, C<$&> is not so costly as the
|
---|
469 | other two.
|
---|
470 | X<$&> X<$`> X<$'>
|
---|
471 |
|
---|
472 | Backslashed metacharacters in Perl are alphanumeric, such as C<\b>,
|
---|
473 | C<\w>, C<\n>. Unlike some other regular expression languages, there
|
---|
474 | are no backslashed symbols that aren't alphanumeric. So anything
|
---|
475 | that looks like \\, \(, \), \<, \>, \{, or \} is always
|
---|
476 | interpreted as a literal character, not a metacharacter. This was
|
---|
477 | once used in a common idiom to disable or quote the special meanings
|
---|
478 | of regular expression metacharacters in a string that you want to
|
---|
479 | use for a pattern. Simply quote all non-"word" characters:
|
---|
480 |
|
---|
481 | $pattern =~ s/(\W)/\\$1/g;
|
---|
482 |
|
---|
483 | (If C<use locale> is set, then this depends on the current locale.)
|
---|
484 | Today it is more common to use the quotemeta() function or the C<\Q>
|
---|
485 | metaquoting escape sequence to disable all metacharacters' special
|
---|
486 | meanings like this:
|
---|
487 |
|
---|
488 | /$unquoted\Q$quoted\E$unquoted/
|
---|
489 |
|
---|
490 | Beware that if you put literal backslashes (those not inside
|
---|
491 | interpolated variables) between C<\Q> and C<\E>, double-quotish
|
---|
492 | backslash interpolation may lead to confusing results. If you
|
---|
493 | I<need> to use literal backslashes within C<\Q...\E>,
|
---|
494 | consult L<perlop/"Gory details of parsing quoted constructs">.
|
---|
495 |
|
---|
496 | =head2 Extended Patterns
|
---|
497 |
|
---|
498 | Perl also defines a consistent extension syntax for features not
|
---|
499 | found in standard tools like B<awk> and B<lex>. The syntax is a
|
---|
500 | pair of parentheses with a question mark as the first thing within
|
---|
501 | the parentheses. The character after the question mark indicates
|
---|
502 | the extension.
|
---|
503 |
|
---|
504 | The stability of these extensions varies widely. Some have been
|
---|
505 | part of the core language for many years. Others are experimental
|
---|
506 | and may change without warning or be completely removed. Check
|
---|
507 | the documentation on an individual feature to verify its current
|
---|
508 | status.
|
---|
509 |
|
---|
510 | A question mark was chosen for this and for the minimal-matching
|
---|
511 | construct because 1) question marks are rare in older regular
|
---|
512 | expressions, and 2) whenever you see one, you should stop and
|
---|
513 | "question" exactly what is going on. That's psychology...
|
---|
514 |
|
---|
515 | =over 10
|
---|
516 |
|
---|
517 | =item C<(?#text)>
|
---|
518 | X<(?#)>
|
---|
519 |
|
---|
520 | A comment. The text is ignored. If the C</x> modifier enables
|
---|
521 | whitespace formatting, a simple C<#> will suffice. Note that Perl closes
|
---|
522 | the comment as soon as it sees a C<)>, so there is no way to put a literal
|
---|
523 | C<)> in the comment.
|
---|
524 |
|
---|
525 | =item C<(?imsx-imsx)>
|
---|
526 | X<(?)>
|
---|
527 |
|
---|
528 | One or more embedded pattern-match modifiers, to be turned on (or
|
---|
529 | turned off, if preceded by C<->) for the remainder of the pattern or
|
---|
530 | the remainder of the enclosing pattern group (if any). This is
|
---|
531 | particularly useful for dynamic patterns, such as those read in from a
|
---|
532 | configuration file, read in as an argument, are specified in a table
|
---|
533 | somewhere, etc. Consider the case that some of which want to be case
|
---|
534 | sensitive and some do not. The case insensitive ones need to include
|
---|
535 | merely C<(?i)> at the front of the pattern. For example:
|
---|
536 |
|
---|
537 | $pattern = "foobar";
|
---|
538 | if ( /$pattern/i ) { }
|
---|
539 |
|
---|
540 | # more flexible:
|
---|
541 |
|
---|
542 | $pattern = "(?i)foobar";
|
---|
543 | if ( /$pattern/ ) { }
|
---|
544 |
|
---|
545 | These modifiers are restored at the end of the enclosing group. For example,
|
---|
546 |
|
---|
547 | ( (?i) blah ) \s+ \1
|
---|
548 |
|
---|
549 | will match a repeated (I<including the case>!) word C<blah> in any
|
---|
550 | case, assuming C<x> modifier, and no C<i> modifier outside this
|
---|
551 | group.
|
---|
552 |
|
---|
553 | =item C<(?:pattern)>
|
---|
554 | X<(?:)>
|
---|
555 |
|
---|
556 | =item C<(?imsx-imsx:pattern)>
|
---|
557 |
|
---|
558 | This is for clustering, not capturing; it groups subexpressions like
|
---|
559 | "()", but doesn't make backreferences as "()" does. So
|
---|
560 |
|
---|
561 | @fields = split(/\b(?:a|b|c)\b/)
|
---|
562 |
|
---|
563 | is like
|
---|
564 |
|
---|
565 | @fields = split(/\b(a|b|c)\b/)
|
---|
566 |
|
---|
567 | but doesn't spit out extra fields. It's also cheaper not to capture
|
---|
568 | characters if you don't need to.
|
---|
569 |
|
---|
570 | Any letters between C<?> and C<:> act as flags modifiers as with
|
---|
571 | C<(?imsx-imsx)>. For example,
|
---|
572 |
|
---|
573 | /(?s-i:more.*than).*million/i
|
---|
574 |
|
---|
575 | is equivalent to the more verbose
|
---|
576 |
|
---|
577 | /(?:(?s-i)more.*than).*million/i
|
---|
578 |
|
---|
579 | =item C<(?=pattern)>
|
---|
580 | X<(?=)> X<look-ahead, positive> X<lookahead, positive>
|
---|
581 |
|
---|
582 | A zero-width positive look-ahead assertion. For example, C</\w+(?=\t)/>
|
---|
583 | matches a word followed by a tab, without including the tab in C<$&>.
|
---|
584 |
|
---|
585 | =item C<(?!pattern)>
|
---|
586 | X<(?!)> X<look-ahead, negative> X<lookahead, negative>
|
---|
587 |
|
---|
588 | A zero-width negative look-ahead assertion. For example C</foo(?!bar)/>
|
---|
589 | matches any occurrence of "foo" that isn't followed by "bar". Note
|
---|
590 | however that look-ahead and look-behind are NOT the same thing. You cannot
|
---|
591 | use this for look-behind.
|
---|
592 |
|
---|
593 | If you are looking for a "bar" that isn't preceded by a "foo", C</(?!foo)bar/>
|
---|
594 | will not do what you want. That's because the C<(?!foo)> is just saying that
|
---|
595 | the next thing cannot be "foo"--and it's not, it's a "bar", so "foobar" will
|
---|
596 | match. You would have to do something like C</(?!foo)...bar/> for that. We
|
---|
597 | say "like" because there's the case of your "bar" not having three characters
|
---|
598 | before it. You could cover that this way: C</(?:(?!foo)...|^.{0,2})bar/>.
|
---|
599 | Sometimes it's still easier just to say:
|
---|
600 |
|
---|
601 | if (/bar/ && $` !~ /foo$/)
|
---|
602 |
|
---|
603 | For look-behind see below.
|
---|
604 |
|
---|
605 | =item C<(?<=pattern)>
|
---|
606 | X<(?<=)> X<look-behind, positive> X<lookbehind, positive>
|
---|
607 |
|
---|
608 | A zero-width positive look-behind assertion. For example, C</(?<=\t)\w+/>
|
---|
609 | matches a word that follows a tab, without including the tab in C<$&>.
|
---|
610 | Works only for fixed-width look-behind.
|
---|
611 |
|
---|
612 | =item C<(?<!pattern)>
|
---|
613 | X<(?<!)> X<look-behind, negative> X<lookbehind, negative>
|
---|
614 |
|
---|
615 | A zero-width negative look-behind assertion. For example C</(?<!bar)foo/>
|
---|
616 | matches any occurrence of "foo" that does not follow "bar". Works
|
---|
617 | only for fixed-width look-behind.
|
---|
618 |
|
---|
619 | =item C<(?{ code })>
|
---|
620 | X<(?{})> X<regex, code in> X<regexp, code in> X<regular expression, code in>
|
---|
621 |
|
---|
622 | B<WARNING>: This extended regular expression feature is considered
|
---|
623 | highly experimental, and may be changed or deleted without notice.
|
---|
624 |
|
---|
625 | This zero-width assertion evaluates any embedded Perl code. It
|
---|
626 | always succeeds, and its C<code> is not interpolated. Currently,
|
---|
627 | the rules to determine where the C<code> ends are somewhat convoluted.
|
---|
628 |
|
---|
629 | This feature can be used together with the special variable C<$^N> to
|
---|
630 | capture the results of submatches in variables without having to keep
|
---|
631 | track of the number of nested parentheses. For example:
|
---|
632 |
|
---|
633 | $_ = "The brown fox jumps over the lazy dog";
|
---|
634 | /the (\S+)(?{ $color = $^N }) (\S+)(?{ $animal = $^N })/i;
|
---|
635 | print "color = $color, animal = $animal\n";
|
---|
636 |
|
---|
637 | Inside the C<(?{...})> block, C<$_> refers to the string the regular
|
---|
638 | expression is matching against. You can also use C<pos()> to know what is
|
---|
639 | the current position of matching within this string.
|
---|
640 |
|
---|
641 | The C<code> is properly scoped in the following sense: If the assertion
|
---|
642 | is backtracked (compare L<"Backtracking">), all changes introduced after
|
---|
643 | C<local>ization are undone, so that
|
---|
644 |
|
---|
645 | $_ = 'a' x 8;
|
---|
646 | m<
|
---|
647 | (?{ $cnt = 0 }) # Initialize $cnt.
|
---|
648 | (
|
---|
649 | a
|
---|
650 | (?{
|
---|
651 | local $cnt = $cnt + 1; # Update $cnt, backtracking-safe.
|
---|
652 | })
|
---|
653 | )*
|
---|
654 | aaaa
|
---|
655 | (?{ $res = $cnt }) # On success copy to non-localized
|
---|
656 | # location.
|
---|
657 | >x;
|
---|
658 |
|
---|
659 | will set C<$res = 4>. Note that after the match, $cnt returns to the globally
|
---|
660 | introduced value, because the scopes that restrict C<local> operators
|
---|
661 | are unwound.
|
---|
662 |
|
---|
663 | This assertion may be used as a C<(?(condition)yes-pattern|no-pattern)>
|
---|
664 | switch. If I<not> used in this way, the result of evaluation of
|
---|
665 | C<code> is put into the special variable C<$^R>. This happens
|
---|
666 | immediately, so C<$^R> can be used from other C<(?{ code })> assertions
|
---|
667 | inside the same regular expression.
|
---|
668 |
|
---|
669 | The assignment to C<$^R> above is properly localized, so the old
|
---|
670 | value of C<$^R> is restored if the assertion is backtracked; compare
|
---|
671 | L<"Backtracking">.
|
---|
672 |
|
---|
673 | For reasons of security, this construct is forbidden if the regular
|
---|
674 | expression involves run-time interpolation of variables, unless the
|
---|
675 | perilous C<use re 'eval'> pragma has been used (see L<re>), or the
|
---|
676 | variables contain results of C<qr//> operator (see
|
---|
677 | L<perlop/"qr/STRING/imosx">).
|
---|
678 |
|
---|
679 | This restriction is because of the wide-spread and remarkably convenient
|
---|
680 | custom of using run-time determined strings as patterns. For example:
|
---|
681 |
|
---|
682 | $re = <>;
|
---|
683 | chomp $re;
|
---|
684 | $string =~ /$re/;
|
---|
685 |
|
---|
686 | Before Perl knew how to execute interpolated code within a pattern,
|
---|
687 | this operation was completely safe from a security point of view,
|
---|
688 | although it could raise an exception from an illegal pattern. If
|
---|
689 | you turn on the C<use re 'eval'>, though, it is no longer secure,
|
---|
690 | so you should only do so if you are also using taint checking.
|
---|
691 | Better yet, use the carefully constrained evaluation within a Safe
|
---|
692 | compartment. See L<perlsec> for details about both these mechanisms.
|
---|
693 |
|
---|
694 | =item C<(??{ code })>
|
---|
695 | X<(??{})>
|
---|
696 | X<regex, postponed> X<regexp, postponed> X<regular expression, postponed>
|
---|
697 | X<regex, recursive> X<regexp, recursive> X<regular expression, recursive>
|
---|
698 |
|
---|
699 | B<WARNING>: This extended regular expression feature is considered
|
---|
700 | highly experimental, and may be changed or deleted without notice.
|
---|
701 | A simplified version of the syntax may be introduced for commonly
|
---|
702 | used idioms.
|
---|
703 |
|
---|
704 | This is a "postponed" regular subexpression. The C<code> is evaluated
|
---|
705 | at run time, at the moment this subexpression may match. The result
|
---|
706 | of evaluation is considered as a regular expression and matched as
|
---|
707 | if it were inserted instead of this construct.
|
---|
708 |
|
---|
709 | The C<code> is not interpolated. As before, the rules to determine
|
---|
710 | where the C<code> ends are currently somewhat convoluted.
|
---|
711 |
|
---|
712 | The following pattern matches a parenthesized group:
|
---|
713 |
|
---|
714 | $re = qr{
|
---|
715 | \(
|
---|
716 | (?:
|
---|
717 | (?> [^()]+ ) # Non-parens without backtracking
|
---|
718 | |
|
---|
719 | (??{ $re }) # Group with matching parens
|
---|
720 | )*
|
---|
721 | \)
|
---|
722 | }x;
|
---|
723 |
|
---|
724 | =item C<< (?>pattern) >>
|
---|
725 | X<backtrack> X<backtracking>
|
---|
726 |
|
---|
727 | B<WARNING>: This extended regular expression feature is considered
|
---|
728 | highly experimental, and may be changed or deleted without notice.
|
---|
729 |
|
---|
730 | An "independent" subexpression, one which matches the substring
|
---|
731 | that a I<standalone> C<pattern> would match if anchored at the given
|
---|
732 | position, and it matches I<nothing other than this substring>. This
|
---|
733 | construct is useful for optimizations of what would otherwise be
|
---|
734 | "eternal" matches, because it will not backtrack (see L<"Backtracking">).
|
---|
735 | It may also be useful in places where the "grab all you can, and do not
|
---|
736 | give anything back" semantic is desirable.
|
---|
737 |
|
---|
738 | For example: C<< ^(?>a*)ab >> will never match, since C<< (?>a*) >>
|
---|
739 | (anchored at the beginning of string, as above) will match I<all>
|
---|
740 | characters C<a> at the beginning of string, leaving no C<a> for
|
---|
741 | C<ab> to match. In contrast, C<a*ab> will match the same as C<a+b>,
|
---|
742 | since the match of the subgroup C<a*> is influenced by the following
|
---|
743 | group C<ab> (see L<"Backtracking">). In particular, C<a*> inside
|
---|
744 | C<a*ab> will match fewer characters than a standalone C<a*>, since
|
---|
745 | this makes the tail match.
|
---|
746 |
|
---|
747 | An effect similar to C<< (?>pattern) >> may be achieved by writing
|
---|
748 | C<(?=(pattern))\1>. This matches the same substring as a standalone
|
---|
749 | C<a+>, and the following C<\1> eats the matched string; it therefore
|
---|
750 | makes a zero-length assertion into an analogue of C<< (?>...) >>.
|
---|
751 | (The difference between these two constructs is that the second one
|
---|
752 | uses a capturing group, thus shifting ordinals of backreferences
|
---|
753 | in the rest of a regular expression.)
|
---|
754 |
|
---|
755 | Consider this pattern:
|
---|
756 |
|
---|
757 | m{ \(
|
---|
758 | (
|
---|
759 | [^()]+ # x+
|
---|
760 | |
|
---|
761 | \( [^()]* \)
|
---|
762 | )+
|
---|
763 | \)
|
---|
764 | }x
|
---|
765 |
|
---|
766 | That will efficiently match a nonempty group with matching parentheses
|
---|
767 | two levels deep or less. However, if there is no such group, it
|
---|
768 | will take virtually forever on a long string. That's because there
|
---|
769 | are so many different ways to split a long string into several
|
---|
770 | substrings. This is what C<(.+)+> is doing, and C<(.+)+> is similar
|
---|
771 | to a subpattern of the above pattern. Consider how the pattern
|
---|
772 | above detects no-match on C<((()aaaaaaaaaaaaaaaaaa> in several
|
---|
773 | seconds, but that each extra letter doubles this time. This
|
---|
774 | exponential performance will make it appear that your program has
|
---|
775 | hung. However, a tiny change to this pattern
|
---|
776 |
|
---|
777 | m{ \(
|
---|
778 | (
|
---|
779 | (?> [^()]+ ) # change x+ above to (?> x+ )
|
---|
780 | |
|
---|
781 | \( [^()]* \)
|
---|
782 | )+
|
---|
783 | \)
|
---|
784 | }x
|
---|
785 |
|
---|
786 | which uses C<< (?>...) >> matches exactly when the one above does (verifying
|
---|
787 | this yourself would be a productive exercise), but finishes in a fourth
|
---|
788 | the time when used on a similar string with 1000000 C<a>s. Be aware,
|
---|
789 | however, that this pattern currently triggers a warning message under
|
---|
790 | the C<use warnings> pragma or B<-w> switch saying it
|
---|
791 | C<"matches null string many times in regex">.
|
---|
792 |
|
---|
793 | On simple groups, such as the pattern C<< (?> [^()]+ ) >>, a comparable
|
---|
794 | effect may be achieved by negative look-ahead, as in C<[^()]+ (?! [^()] )>.
|
---|
795 | This was only 4 times slower on a string with 1000000 C<a>s.
|
---|
796 |
|
---|
797 | The "grab all you can, and do not give anything back" semantic is desirable
|
---|
798 | in many situations where on the first sight a simple C<()*> looks like
|
---|
799 | the correct solution. Suppose we parse text with comments being delimited
|
---|
800 | by C<#> followed by some optional (horizontal) whitespace. Contrary to
|
---|
801 | its appearance, C<#[ \t]*> I<is not> the correct subexpression to match
|
---|
802 | the comment delimiter, because it may "give up" some whitespace if
|
---|
803 | the remainder of the pattern can be made to match that way. The correct
|
---|
804 | answer is either one of these:
|
---|
805 |
|
---|
806 | (?>#[ \t]*)
|
---|
807 | #[ \t]*(?![ \t])
|
---|
808 |
|
---|
809 | For example, to grab non-empty comments into $1, one should use either
|
---|
810 | one of these:
|
---|
811 |
|
---|
812 | / (?> \# [ \t]* ) ( .+ ) /x;
|
---|
813 | / \# [ \t]* ( [^ \t] .* ) /x;
|
---|
814 |
|
---|
815 | Which one you pick depends on which of these expressions better reflects
|
---|
816 | the above specification of comments.
|
---|
817 |
|
---|
818 | =item C<(?(condition)yes-pattern|no-pattern)>
|
---|
819 | X<(?()>
|
---|
820 |
|
---|
821 | =item C<(?(condition)yes-pattern)>
|
---|
822 |
|
---|
823 | B<WARNING>: This extended regular expression feature is considered
|
---|
824 | highly experimental, and may be changed or deleted without notice.
|
---|
825 |
|
---|
826 | Conditional expression. C<(condition)> should be either an integer in
|
---|
827 | parentheses (which is valid if the corresponding pair of parentheses
|
---|
828 | matched), or look-ahead/look-behind/evaluate zero-width assertion.
|
---|
829 |
|
---|
830 | For example:
|
---|
831 |
|
---|
832 | m{ ( \( )?
|
---|
833 | [^()]+
|
---|
834 | (?(1) \) )
|
---|
835 | }x
|
---|
836 |
|
---|
837 | matches a chunk of non-parentheses, possibly included in parentheses
|
---|
838 | themselves.
|
---|
839 |
|
---|
840 | =back
|
---|
841 |
|
---|
842 | =head2 Backtracking
|
---|
843 | X<backtrack> X<backtracking>
|
---|
844 |
|
---|
845 | NOTE: This section presents an abstract approximation of regular
|
---|
846 | expression behavior. For a more rigorous (and complicated) view of
|
---|
847 | the rules involved in selecting a match among possible alternatives,
|
---|
848 | see L<Combining pieces together>.
|
---|
849 |
|
---|
850 | A fundamental feature of regular expression matching involves the
|
---|
851 | notion called I<backtracking>, which is currently used (when needed)
|
---|
852 | by all regular expression quantifiers, namely C<*>, C<*?>, C<+>,
|
---|
853 | C<+?>, C<{n,m}>, and C<{n,m}?>. Backtracking is often optimized
|
---|
854 | internally, but the general principle outlined here is valid.
|
---|
855 |
|
---|
856 | For a regular expression to match, the I<entire> regular expression must
|
---|
857 | match, not just part of it. So if the beginning of a pattern containing a
|
---|
858 | quantifier succeeds in a way that causes later parts in the pattern to
|
---|
859 | fail, the matching engine backs up and recalculates the beginning
|
---|
860 | part--that's why it's called backtracking.
|
---|
861 |
|
---|
862 | Here is an example of backtracking: Let's say you want to find the
|
---|
863 | word following "foo" in the string "Food is on the foo table.":
|
---|
864 |
|
---|
865 | $_ = "Food is on the foo table.";
|
---|
866 | if ( /\b(foo)\s+(\w+)/i ) {
|
---|
867 | print "$2 follows $1.\n";
|
---|
868 | }
|
---|
869 |
|
---|
870 | When the match runs, the first part of the regular expression (C<\b(foo)>)
|
---|
871 | finds a possible match right at the beginning of the string, and loads up
|
---|
872 | $1 with "Foo". However, as soon as the matching engine sees that there's
|
---|
873 | no whitespace following the "Foo" that it had saved in $1, it realizes its
|
---|
874 | mistake and starts over again one character after where it had the
|
---|
875 | tentative match. This time it goes all the way until the next occurrence
|
---|
876 | of "foo". The complete regular expression matches this time, and you get
|
---|
877 | the expected output of "table follows foo."
|
---|
878 |
|
---|
879 | Sometimes minimal matching can help a lot. Imagine you'd like to match
|
---|
880 | everything between "foo" and "bar". Initially, you write something
|
---|
881 | like this:
|
---|
882 |
|
---|
883 | $_ = "The food is under the bar in the barn.";
|
---|
884 | if ( /foo(.*)bar/ ) {
|
---|
885 | print "got <$1>\n";
|
---|
886 | }
|
---|
887 |
|
---|
888 | Which perhaps unexpectedly yields:
|
---|
889 |
|
---|
890 | got <d is under the bar in the >
|
---|
891 |
|
---|
892 | That's because C<.*> was greedy, so you get everything between the
|
---|
893 | I<first> "foo" and the I<last> "bar". Here it's more effective
|
---|
894 | to use minimal matching to make sure you get the text between a "foo"
|
---|
895 | and the first "bar" thereafter.
|
---|
896 |
|
---|
897 | if ( /foo(.*?)bar/ ) { print "got <$1>\n" }
|
---|
898 | got <d is under the >
|
---|
899 |
|
---|
900 | Here's another example: let's say you'd like to match a number at the end
|
---|
901 | of a string, and you also want to keep the preceding part of the match.
|
---|
902 | So you write this:
|
---|
903 |
|
---|
904 | $_ = "I have 2 numbers: 53147";
|
---|
905 | if ( /(.*)(\d*)/ ) { # Wrong!
|
---|
906 | print "Beginning is <$1>, number is <$2>.\n";
|
---|
907 | }
|
---|
908 |
|
---|
909 | That won't work at all, because C<.*> was greedy and gobbled up the
|
---|
910 | whole string. As C<\d*> can match on an empty string the complete
|
---|
911 | regular expression matched successfully.
|
---|
912 |
|
---|
913 | Beginning is <I have 2 numbers: 53147>, number is <>.
|
---|
914 |
|
---|
915 | Here are some variants, most of which don't work:
|
---|
916 |
|
---|
917 | $_ = "I have 2 numbers: 53147";
|
---|
918 | @pats = qw{
|
---|
919 | (.*)(\d*)
|
---|
920 | (.*)(\d+)
|
---|
921 | (.*?)(\d*)
|
---|
922 | (.*?)(\d+)
|
---|
923 | (.*)(\d+)$
|
---|
924 | (.*?)(\d+)$
|
---|
925 | (.*)\b(\d+)$
|
---|
926 | (.*\D)(\d+)$
|
---|
927 | };
|
---|
928 |
|
---|
929 | for $pat (@pats) {
|
---|
930 | printf "%-12s ", $pat;
|
---|
931 | if ( /$pat/ ) {
|
---|
932 | print "<$1> <$2>\n";
|
---|
933 | } else {
|
---|
934 | print "FAIL\n";
|
---|
935 | }
|
---|
936 | }
|
---|
937 |
|
---|
938 | That will print out:
|
---|
939 |
|
---|
940 | (.*)(\d*) <I have 2 numbers: 53147> <>
|
---|
941 | (.*)(\d+) <I have 2 numbers: 5314> <7>
|
---|
942 | (.*?)(\d*) <> <>
|
---|
943 | (.*?)(\d+) <I have > <2>
|
---|
944 | (.*)(\d+)$ <I have 2 numbers: 5314> <7>
|
---|
945 | (.*?)(\d+)$ <I have 2 numbers: > <53147>
|
---|
946 | (.*)\b(\d+)$ <I have 2 numbers: > <53147>
|
---|
947 | (.*\D)(\d+)$ <I have 2 numbers: > <53147>
|
---|
948 |
|
---|
949 | As you see, this can be a bit tricky. It's important to realize that a
|
---|
950 | regular expression is merely a set of assertions that gives a definition
|
---|
951 | of success. There may be 0, 1, or several different ways that the
|
---|
952 | definition might succeed against a particular string. And if there are
|
---|
953 | multiple ways it might succeed, you need to understand backtracking to
|
---|
954 | know which variety of success you will achieve.
|
---|
955 |
|
---|
956 | When using look-ahead assertions and negations, this can all get even
|
---|
957 | trickier. Imagine you'd like to find a sequence of non-digits not
|
---|
958 | followed by "123". You might try to write that as
|
---|
959 |
|
---|
960 | $_ = "ABC123";
|
---|
961 | if ( /^\D*(?!123)/ ) { # Wrong!
|
---|
962 | print "Yup, no 123 in $_\n";
|
---|
963 | }
|
---|
964 |
|
---|
965 | But that isn't going to match; at least, not the way you're hoping. It
|
---|
966 | claims that there is no 123 in the string. Here's a clearer picture of
|
---|
967 | why that pattern matches, contrary to popular expectations:
|
---|
968 |
|
---|
969 | $x = 'ABC123';
|
---|
970 | $y = 'ABC445';
|
---|
971 |
|
---|
972 | print "1: got $1\n" if $x =~ /^(ABC)(?!123)/;
|
---|
973 | print "2: got $1\n" if $y =~ /^(ABC)(?!123)/;
|
---|
974 |
|
---|
975 | print "3: got $1\n" if $x =~ /^(\D*)(?!123)/;
|
---|
976 | print "4: got $1\n" if $y =~ /^(\D*)(?!123)/;
|
---|
977 |
|
---|
978 | This prints
|
---|
979 |
|
---|
980 | 2: got ABC
|
---|
981 | 3: got AB
|
---|
982 | 4: got ABC
|
---|
983 |
|
---|
984 | You might have expected test 3 to fail because it seems to a more
|
---|
985 | general purpose version of test 1. The important difference between
|
---|
986 | them is that test 3 contains a quantifier (C<\D*>) and so can use
|
---|
987 | backtracking, whereas test 1 will not. What's happening is
|
---|
988 | that you've asked "Is it true that at the start of $x, following 0 or more
|
---|
989 | non-digits, you have something that's not 123?" If the pattern matcher had
|
---|
990 | let C<\D*> expand to "ABC", this would have caused the whole pattern to
|
---|
991 | fail.
|
---|
992 |
|
---|
993 | The search engine will initially match C<\D*> with "ABC". Then it will
|
---|
994 | try to match C<(?!123> with "123", which fails. But because
|
---|
995 | a quantifier (C<\D*>) has been used in the regular expression, the
|
---|
996 | search engine can backtrack and retry the match differently
|
---|
997 | in the hope of matching the complete regular expression.
|
---|
998 |
|
---|
999 | The pattern really, I<really> wants to succeed, so it uses the
|
---|
1000 | standard pattern back-off-and-retry and lets C<\D*> expand to just "AB" this
|
---|
1001 | time. Now there's indeed something following "AB" that is not
|
---|
1002 | "123". It's "C123", which suffices.
|
---|
1003 |
|
---|
1004 | We can deal with this by using both an assertion and a negation.
|
---|
1005 | We'll say that the first part in $1 must be followed both by a digit
|
---|
1006 | and by something that's not "123". Remember that the look-aheads
|
---|
1007 | are zero-width expressions--they only look, but don't consume any
|
---|
1008 | of the string in their match. So rewriting this way produces what
|
---|
1009 | you'd expect; that is, case 5 will fail, but case 6 succeeds:
|
---|
1010 |
|
---|
1011 | print "5: got $1\n" if $x =~ /^(\D*)(?=\d)(?!123)/;
|
---|
1012 | print "6: got $1\n" if $y =~ /^(\D*)(?=\d)(?!123)/;
|
---|
1013 |
|
---|
1014 | 6: got ABC
|
---|
1015 |
|
---|
1016 | In other words, the two zero-width assertions next to each other work as though
|
---|
1017 | they're ANDed together, just as you'd use any built-in assertions: C</^$/>
|
---|
1018 | matches only if you're at the beginning of the line AND the end of the
|
---|
1019 | line simultaneously. The deeper underlying truth is that juxtaposition in
|
---|
1020 | regular expressions always means AND, except when you write an explicit OR
|
---|
1021 | using the vertical bar. C</ab/> means match "a" AND (then) match "b",
|
---|
1022 | although the attempted matches are made at different positions because "a"
|
---|
1023 | is not a zero-width assertion, but a one-width assertion.
|
---|
1024 |
|
---|
1025 | B<WARNING>: particularly complicated regular expressions can take
|
---|
1026 | exponential time to solve because of the immense number of possible
|
---|
1027 | ways they can use backtracking to try match. For example, without
|
---|
1028 | internal optimizations done by the regular expression engine, this will
|
---|
1029 | take a painfully long time to run:
|
---|
1030 |
|
---|
1031 | 'aaaaaaaaaaaa' =~ /((a{0,5}){0,5})*[c]/
|
---|
1032 |
|
---|
1033 | And if you used C<*>'s in the internal groups instead of limiting them
|
---|
1034 | to 0 through 5 matches, then it would take forever--or until you ran
|
---|
1035 | out of stack space. Moreover, these internal optimizations are not
|
---|
1036 | always applicable. For example, if you put C<{0,5}> instead of C<*>
|
---|
1037 | on the external group, no current optimization is applicable, and the
|
---|
1038 | match takes a long time to finish.
|
---|
1039 |
|
---|
1040 | A powerful tool for optimizing such beasts is what is known as an
|
---|
1041 | "independent group",
|
---|
1042 | which does not backtrack (see L<C<< (?>pattern) >>>). Note also that
|
---|
1043 | zero-length look-ahead/look-behind assertions will not backtrack to make
|
---|
1044 | the tail match, since they are in "logical" context: only
|
---|
1045 | whether they match is considered relevant. For an example
|
---|
1046 | where side-effects of look-ahead I<might> have influenced the
|
---|
1047 | following match, see L<C<< (?>pattern) >>>.
|
---|
1048 |
|
---|
1049 | =head2 Version 8 Regular Expressions
|
---|
1050 | X<regular expression, version 8> X<regex, version 8> X<regexp, version 8>
|
---|
1051 |
|
---|
1052 | In case you're not familiar with the "regular" Version 8 regex
|
---|
1053 | routines, here are the pattern-matching rules not described above.
|
---|
1054 |
|
---|
1055 | Any single character matches itself, unless it is a I<metacharacter>
|
---|
1056 | with a special meaning described here or above. You can cause
|
---|
1057 | characters that normally function as metacharacters to be interpreted
|
---|
1058 | literally by prefixing them with a "\" (e.g., "\." matches a ".", not any
|
---|
1059 | character; "\\" matches a "\"). A series of characters matches that
|
---|
1060 | series of characters in the target string, so the pattern C<blurfl>
|
---|
1061 | would match "blurfl" in the target string.
|
---|
1062 |
|
---|
1063 | You can specify a character class, by enclosing a list of characters
|
---|
1064 | in C<[]>, which will match any one character from the list. If the
|
---|
1065 | first character after the "[" is "^", the class matches any character not
|
---|
1066 | in the list. Within a list, the "-" character specifies a
|
---|
1067 | range, so that C<a-z> represents all characters between "a" and "z",
|
---|
1068 | inclusive. If you want either "-" or "]" itself to be a member of a
|
---|
1069 | class, put it at the start of the list (possibly after a "^"), or
|
---|
1070 | escape it with a backslash. "-" is also taken literally when it is
|
---|
1071 | at the end of the list, just before the closing "]". (The
|
---|
1072 | following all specify the same class of three characters: C<[-az]>,
|
---|
1073 | C<[az-]>, and C<[a\-z]>. All are different from C<[a-z]>, which
|
---|
1074 | specifies a class containing twenty-six characters, even on EBCDIC
|
---|
1075 | based coded character sets.) Also, if you try to use the character
|
---|
1076 | classes C<\w>, C<\W>, C<\s>, C<\S>, C<\d>, or C<\D> as endpoints of
|
---|
1077 | a range, that's not a range, the "-" is understood literally.
|
---|
1078 |
|
---|
1079 | Note also that the whole range idea is rather unportable between
|
---|
1080 | character sets--and even within character sets they may cause results
|
---|
1081 | you probably didn't expect. A sound principle is to use only ranges
|
---|
1082 | that begin from and end at either alphabets of equal case ([a-e],
|
---|
1083 | [A-E]), or digits ([0-9]). Anything else is unsafe. If in doubt,
|
---|
1084 | spell out the character sets in full.
|
---|
1085 |
|
---|
1086 | Characters may be specified using a metacharacter syntax much like that
|
---|
1087 | used in C: "\n" matches a newline, "\t" a tab, "\r" a carriage return,
|
---|
1088 | "\f" a form feed, etc. More generally, \I<nnn>, where I<nnn> is a string
|
---|
1089 | of octal digits, matches the character whose coded character set value
|
---|
1090 | is I<nnn>. Similarly, \xI<nn>, where I<nn> are hexadecimal digits,
|
---|
1091 | matches the character whose numeric value is I<nn>. The expression \cI<x>
|
---|
1092 | matches the character control-I<x>. Finally, the "." metacharacter
|
---|
1093 | matches any character except "\n" (unless you use C</s>).
|
---|
1094 |
|
---|
1095 | You can specify a series of alternatives for a pattern using "|" to
|
---|
1096 | separate them, so that C<fee|fie|foe> will match any of "fee", "fie",
|
---|
1097 | or "foe" in the target string (as would C<f(e|i|o)e>). The
|
---|
1098 | first alternative includes everything from the last pattern delimiter
|
---|
1099 | ("(", "[", or the beginning of the pattern) up to the first "|", and
|
---|
1100 | the last alternative contains everything from the last "|" to the next
|
---|
1101 | pattern delimiter. That's why it's common practice to include
|
---|
1102 | alternatives in parentheses: to minimize confusion about where they
|
---|
1103 | start and end.
|
---|
1104 |
|
---|
1105 | Alternatives are tried from left to right, so the first
|
---|
1106 | alternative found for which the entire expression matches, is the one that
|
---|
1107 | is chosen. This means that alternatives are not necessarily greedy. For
|
---|
1108 | example: when matching C<foo|foot> against "barefoot", only the "foo"
|
---|
1109 | part will match, as that is the first alternative tried, and it successfully
|
---|
1110 | matches the target string. (This might not seem important, but it is
|
---|
1111 | important when you are capturing matched text using parentheses.)
|
---|
1112 |
|
---|
1113 | Also remember that "|" is interpreted as a literal within square brackets,
|
---|
1114 | so if you write C<[fee|fie|foe]> you're really only matching C<[feio|]>.
|
---|
1115 |
|
---|
1116 | Within a pattern, you may designate subpatterns for later reference
|
---|
1117 | by enclosing them in parentheses, and you may refer back to the
|
---|
1118 | I<n>th subpattern later in the pattern using the metacharacter
|
---|
1119 | \I<n>. Subpatterns are numbered based on the left to right order
|
---|
1120 | of their opening parenthesis. A backreference matches whatever
|
---|
1121 | actually matched the subpattern in the string being examined, not
|
---|
1122 | the rules for that subpattern. Therefore, C<(0|0x)\d*\s\1\d*> will
|
---|
1123 | match "0x1234 0x4321", but not "0x1234 01234", because subpattern
|
---|
1124 | 1 matched "0x", even though the rule C<0|0x> could potentially match
|
---|
1125 | the leading 0 in the second number.
|
---|
1126 |
|
---|
1127 | =head2 Warning on \1 vs $1
|
---|
1128 |
|
---|
1129 | Some people get too used to writing things like:
|
---|
1130 |
|
---|
1131 | $pattern =~ s/(\W)/\\\1/g;
|
---|
1132 |
|
---|
1133 | This is grandfathered for the RHS of a substitute to avoid shocking the
|
---|
1134 | B<sed> addicts, but it's a dirty habit to get into. That's because in
|
---|
1135 | PerlThink, the righthand side of an C<s///> is a double-quoted string. C<\1> in
|
---|
1136 | the usual double-quoted string means a control-A. The customary Unix
|
---|
1137 | meaning of C<\1> is kludged in for C<s///>. However, if you get into the habit
|
---|
1138 | of doing that, you get yourself into trouble if you then add an C</e>
|
---|
1139 | modifier.
|
---|
1140 |
|
---|
1141 | s/(\d+)/ \1 + 1 /eg; # causes warning under -w
|
---|
1142 |
|
---|
1143 | Or if you try to do
|
---|
1144 |
|
---|
1145 | s/(\d+)/\1000/;
|
---|
1146 |
|
---|
1147 | You can't disambiguate that by saying C<\{1}000>, whereas you can fix it with
|
---|
1148 | C<${1}000>. The operation of interpolation should not be confused
|
---|
1149 | with the operation of matching a backreference. Certainly they mean two
|
---|
1150 | different things on the I<left> side of the C<s///>.
|
---|
1151 |
|
---|
1152 | =head2 Repeated patterns matching zero-length substring
|
---|
1153 |
|
---|
1154 | B<WARNING>: Difficult material (and prose) ahead. This section needs a rewrite.
|
---|
1155 |
|
---|
1156 | Regular expressions provide a terse and powerful programming language. As
|
---|
1157 | with most other power tools, power comes together with the ability
|
---|
1158 | to wreak havoc.
|
---|
1159 |
|
---|
1160 | A common abuse of this power stems from the ability to make infinite
|
---|
1161 | loops using regular expressions, with something as innocuous as:
|
---|
1162 |
|
---|
1163 | 'foo' =~ m{ ( o? )* }x;
|
---|
1164 |
|
---|
1165 | The C<o?> can match at the beginning of C<'foo'>, and since the position
|
---|
1166 | in the string is not moved by the match, C<o?> would match again and again
|
---|
1167 | because of the C<*> modifier. Another common way to create a similar cycle
|
---|
1168 | is with the looping modifier C<//g>:
|
---|
1169 |
|
---|
1170 | @matches = ( 'foo' =~ m{ o? }xg );
|
---|
1171 |
|
---|
1172 | or
|
---|
1173 |
|
---|
1174 | print "match: <$&>\n" while 'foo' =~ m{ o? }xg;
|
---|
1175 |
|
---|
1176 | or the loop implied by split().
|
---|
1177 |
|
---|
1178 | However, long experience has shown that many programming tasks may
|
---|
1179 | be significantly simplified by using repeated subexpressions that
|
---|
1180 | may match zero-length substrings. Here's a simple example being:
|
---|
1181 |
|
---|
1182 | @chars = split //, $string; # // is not magic in split
|
---|
1183 | ($whitewashed = $string) =~ s/()/ /g; # parens avoid magic s// /
|
---|
1184 |
|
---|
1185 | Thus Perl allows such constructs, by I<forcefully breaking
|
---|
1186 | the infinite loop>. The rules for this are different for lower-level
|
---|
1187 | loops given by the greedy modifiers C<*+{}>, and for higher-level
|
---|
1188 | ones like the C</g> modifier or split() operator.
|
---|
1189 |
|
---|
1190 | The lower-level loops are I<interrupted> (that is, the loop is
|
---|
1191 | broken) when Perl detects that a repeated expression matched a
|
---|
1192 | zero-length substring. Thus
|
---|
1193 |
|
---|
1194 | m{ (?: NON_ZERO_LENGTH | ZERO_LENGTH )* }x;
|
---|
1195 |
|
---|
1196 | is made equivalent to
|
---|
1197 |
|
---|
1198 | m{ (?: NON_ZERO_LENGTH )*
|
---|
1199 | |
|
---|
1200 | (?: ZERO_LENGTH )?
|
---|
1201 | }x;
|
---|
1202 |
|
---|
1203 | The higher level-loops preserve an additional state between iterations:
|
---|
1204 | whether the last match was zero-length. To break the loop, the following
|
---|
1205 | match after a zero-length match is prohibited to have a length of zero.
|
---|
1206 | This prohibition interacts with backtracking (see L<"Backtracking">),
|
---|
1207 | and so the I<second best> match is chosen if the I<best> match is of
|
---|
1208 | zero length.
|
---|
1209 |
|
---|
1210 | For example:
|
---|
1211 |
|
---|
1212 | $_ = 'bar';
|
---|
1213 | s/\w??/<$&>/g;
|
---|
1214 |
|
---|
1215 | results in C<< <><b><><a><><r><> >>. At each position of the string the best
|
---|
1216 | match given by non-greedy C<??> is the zero-length match, and the I<second
|
---|
1217 | best> match is what is matched by C<\w>. Thus zero-length matches
|
---|
1218 | alternate with one-character-long matches.
|
---|
1219 |
|
---|
1220 | Similarly, for repeated C<m/()/g> the second-best match is the match at the
|
---|
1221 | position one notch further in the string.
|
---|
1222 |
|
---|
1223 | The additional state of being I<matched with zero-length> is associated with
|
---|
1224 | the matched string, and is reset by each assignment to pos().
|
---|
1225 | Zero-length matches at the end of the previous match are ignored
|
---|
1226 | during C<split>.
|
---|
1227 |
|
---|
1228 | =head2 Combining pieces together
|
---|
1229 |
|
---|
1230 | Each of the elementary pieces of regular expressions which were described
|
---|
1231 | before (such as C<ab> or C<\Z>) could match at most one substring
|
---|
1232 | at the given position of the input string. However, in a typical regular
|
---|
1233 | expression these elementary pieces are combined into more complicated
|
---|
1234 | patterns using combining operators C<ST>, C<S|T>, C<S*> etc
|
---|
1235 | (in these examples C<S> and C<T> are regular subexpressions).
|
---|
1236 |
|
---|
1237 | Such combinations can include alternatives, leading to a problem of choice:
|
---|
1238 | if we match a regular expression C<a|ab> against C<"abc">, will it match
|
---|
1239 | substring C<"a"> or C<"ab">? One way to describe which substring is
|
---|
1240 | actually matched is the concept of backtracking (see L<"Backtracking">).
|
---|
1241 | However, this description is too low-level and makes you think
|
---|
1242 | in terms of a particular implementation.
|
---|
1243 |
|
---|
1244 | Another description starts with notions of "better"/"worse". All the
|
---|
1245 | substrings which may be matched by the given regular expression can be
|
---|
1246 | sorted from the "best" match to the "worst" match, and it is the "best"
|
---|
1247 | match which is chosen. This substitutes the question of "what is chosen?"
|
---|
1248 | by the question of "which matches are better, and which are worse?".
|
---|
1249 |
|
---|
1250 | Again, for elementary pieces there is no such question, since at most
|
---|
1251 | one match at a given position is possible. This section describes the
|
---|
1252 | notion of better/worse for combining operators. In the description
|
---|
1253 | below C<S> and C<T> are regular subexpressions.
|
---|
1254 |
|
---|
1255 | =over 4
|
---|
1256 |
|
---|
1257 | =item C<ST>
|
---|
1258 |
|
---|
1259 | Consider two possible matches, C<AB> and C<A'B'>, C<A> and C<A'> are
|
---|
1260 | substrings which can be matched by C<S>, C<B> and C<B'> are substrings
|
---|
1261 | which can be matched by C<T>.
|
---|
1262 |
|
---|
1263 | If C<A> is better match for C<S> than C<A'>, C<AB> is a better
|
---|
1264 | match than C<A'B'>.
|
---|
1265 |
|
---|
1266 | If C<A> and C<A'> coincide: C<AB> is a better match than C<AB'> if
|
---|
1267 | C<B> is better match for C<T> than C<B'>.
|
---|
1268 |
|
---|
1269 | =item C<S|T>
|
---|
1270 |
|
---|
1271 | When C<S> can match, it is a better match than when only C<T> can match.
|
---|
1272 |
|
---|
1273 | Ordering of two matches for C<S> is the same as for C<S>. Similar for
|
---|
1274 | two matches for C<T>.
|
---|
1275 |
|
---|
1276 | =item C<S{REPEAT_COUNT}>
|
---|
1277 |
|
---|
1278 | Matches as C<SSS...S> (repeated as many times as necessary).
|
---|
1279 |
|
---|
1280 | =item C<S{min,max}>
|
---|
1281 |
|
---|
1282 | Matches as C<S{max}|S{max-1}|...|S{min+1}|S{min}>.
|
---|
1283 |
|
---|
1284 | =item C<S{min,max}?>
|
---|
1285 |
|
---|
1286 | Matches as C<S{min}|S{min+1}|...|S{max-1}|S{max}>.
|
---|
1287 |
|
---|
1288 | =item C<S?>, C<S*>, C<S+>
|
---|
1289 |
|
---|
1290 | Same as C<S{0,1}>, C<S{0,BIG_NUMBER}>, C<S{1,BIG_NUMBER}> respectively.
|
---|
1291 |
|
---|
1292 | =item C<S??>, C<S*?>, C<S+?>
|
---|
1293 |
|
---|
1294 | Same as C<S{0,1}?>, C<S{0,BIG_NUMBER}?>, C<S{1,BIG_NUMBER}?> respectively.
|
---|
1295 |
|
---|
1296 | =item C<< (?>S) >>
|
---|
1297 |
|
---|
1298 | Matches the best match for C<S> and only that.
|
---|
1299 |
|
---|
1300 | =item C<(?=S)>, C<(?<=S)>
|
---|
1301 |
|
---|
1302 | Only the best match for C<S> is considered. (This is important only if
|
---|
1303 | C<S> has capturing parentheses, and backreferences are used somewhere
|
---|
1304 | else in the whole regular expression.)
|
---|
1305 |
|
---|
1306 | =item C<(?!S)>, C<(?<!S)>
|
---|
1307 |
|
---|
1308 | For this grouping operator there is no need to describe the ordering, since
|
---|
1309 | only whether or not C<S> can match is important.
|
---|
1310 |
|
---|
1311 | =item C<(??{ EXPR })>
|
---|
1312 |
|
---|
1313 | The ordering is the same as for the regular expression which is
|
---|
1314 | the result of EXPR.
|
---|
1315 |
|
---|
1316 | =item C<(?(condition)yes-pattern|no-pattern)>
|
---|
1317 |
|
---|
1318 | Recall that which of C<yes-pattern> or C<no-pattern> actually matches is
|
---|
1319 | already determined. The ordering of the matches is the same as for the
|
---|
1320 | chosen subexpression.
|
---|
1321 |
|
---|
1322 | =back
|
---|
1323 |
|
---|
1324 | The above recipes describe the ordering of matches I<at a given position>.
|
---|
1325 | One more rule is needed to understand how a match is determined for the
|
---|
1326 | whole regular expression: a match at an earlier position is always better
|
---|
1327 | than a match at a later position.
|
---|
1328 |
|
---|
1329 | =head2 Creating custom RE engines
|
---|
1330 |
|
---|
1331 | Overloaded constants (see L<overload>) provide a simple way to extend
|
---|
1332 | the functionality of the RE engine.
|
---|
1333 |
|
---|
1334 | Suppose that we want to enable a new RE escape-sequence C<\Y|> which
|
---|
1335 | matches at boundary between whitespace characters and non-whitespace
|
---|
1336 | characters. Note that C<(?=\S)(?<!\S)|(?!\S)(?<=\S)> matches exactly
|
---|
1337 | at these positions, so we want to have each C<\Y|> in the place of the
|
---|
1338 | more complicated version. We can create a module C<customre> to do
|
---|
1339 | this:
|
---|
1340 |
|
---|
1341 | package customre;
|
---|
1342 | use overload;
|
---|
1343 |
|
---|
1344 | sub import {
|
---|
1345 | shift;
|
---|
1346 | die "No argument to customre::import allowed" if @_;
|
---|
1347 | overload::constant 'qr' => \&convert;
|
---|
1348 | }
|
---|
1349 |
|
---|
1350 | sub invalid { die "/$_[0]/: invalid escape '\\$_[1]'"}
|
---|
1351 |
|
---|
1352 | # We must also take care of not escaping the legitimate \\Y|
|
---|
1353 | # sequence, hence the presence of '\\' in the conversion rules.
|
---|
1354 | my %rules = ( '\\' => '\\\\',
|
---|
1355 | 'Y|' => qr/(?=\S)(?<!\S)|(?!\S)(?<=\S)/ );
|
---|
1356 | sub convert {
|
---|
1357 | my $re = shift;
|
---|
1358 | $re =~ s{
|
---|
1359 | \\ ( \\ | Y . )
|
---|
1360 | }
|
---|
1361 | { $rules{$1} or invalid($re,$1) }sgex;
|
---|
1362 | return $re;
|
---|
1363 | }
|
---|
1364 |
|
---|
1365 | Now C<use customre> enables the new escape in constant regular
|
---|
1366 | expressions, i.e., those without any runtime variable interpolations.
|
---|
1367 | As documented in L<overload>, this conversion will work only over
|
---|
1368 | literal parts of regular expressions. For C<\Y|$re\Y|> the variable
|
---|
1369 | part of this regular expression needs to be converted explicitly
|
---|
1370 | (but only if the special meaning of C<\Y|> should be enabled inside $re):
|
---|
1371 |
|
---|
1372 | use customre;
|
---|
1373 | $re = <>;
|
---|
1374 | chomp $re;
|
---|
1375 | $re = customre::convert $re;
|
---|
1376 | /\Y|$re\Y|/;
|
---|
1377 |
|
---|
1378 | =head1 BUGS
|
---|
1379 |
|
---|
1380 | This document varies from difficult to understand to completely
|
---|
1381 | and utterly opaque. The wandering prose riddled with jargon is
|
---|
1382 | hard to fathom in several places.
|
---|
1383 |
|
---|
1384 | This document needs a rewrite that separates the tutorial content
|
---|
1385 | from the reference content.
|
---|
1386 |
|
---|
1387 | =head1 SEE ALSO
|
---|
1388 |
|
---|
1389 | L<perlrequick>.
|
---|
1390 |
|
---|
1391 | L<perlretut>.
|
---|
1392 |
|
---|
1393 | L<perlop/"Regexp Quote-Like Operators">.
|
---|
1394 |
|
---|
1395 | L<perlop/"Gory details of parsing quoted constructs">.
|
---|
1396 |
|
---|
1397 | L<perlfaq6>.
|
---|
1398 |
|
---|
1399 | L<perlfunc/pos>.
|
---|
1400 |
|
---|
1401 | L<perllocale>.
|
---|
1402 |
|
---|
1403 | L<perlebcdic>.
|
---|
1404 |
|
---|
1405 | I<Mastering Regular Expressions> by Jeffrey Friedl, published
|
---|
1406 | by O'Reilly and Associates.
|
---|