In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/9fa86798943f58593c0291be5acd91b348948336?hp=df8b844e71ddcff72baee26af372af079dd52c0f>
- Log ----------------------------------------------------------------- commit 9fa86798943f58593c0291be5acd91b348948336 Author: Father Chrysostomos <[email protected]> Date: Tue Mar 8 12:01:44 2011 -0800 Mention when reflags was added M pod/perlretut.pod commit 39b6ec1a4f067ccc33bb32fe5d2157b96637d2c5 Author: Father Chrysostomos <[email protected]> Date: Mon Mar 7 22:53:18 2011 -0800 Another typo in perlretut M pod/perlretut.pod commit 511eb43017d1a01e9160c59358f5e4498ef387b2 Author: Father Chrysostomos <[email protected]> Date: Mon Mar 7 22:49:03 2011 -0800 mention reflags in perlretut M pod/perlretut.pod commit 6b3ddc029cf819ff0f298f4489b08bbcc940dfe4 Author: Father Chrysostomos <[email protected]> Date: Mon Mar 7 22:45:35 2011 -0800 Even more perlretut tweaks M pod/perlretut.pod ----------------------------------------------------------------------- Summary of changes: pod/perlretut.pod | 29 +++++++++++++++++++---------- 1 files changed, 19 insertions(+), 10 deletions(-) diff --git a/pod/perlretut.pod b/pod/perlretut.pod index efc7f04..0872e0a 100644 --- a/pod/perlretut.pod +++ b/pod/perlretut.pod @@ -2163,8 +2163,8 @@ Starting with this section, we will be discussing Perl's set of I<extended patterns>. These are extensions to the traditional regular expression syntax that provide powerful new tools for pattern matching. We have already seen extensions in the form of the minimal -matching constructs C<??>, C<*?>, C<+?>, C<{n,m}?>, and C<{n,}?>. The -rest of the extensions below have the form C<(?char...)>, where the +matching constructs C<??>, C<*?>, C<+?>, C<{n,m}?>, and C<{n,}?>. Most +of the extensions below have the form C<(?char...)>, where the C<char> is a character that determines the type of extension. The first extension is an embedded comment C<(?#text)>. This embeds a @@ -2235,8 +2235,8 @@ we have seen so far are the anchors. The anchor C<^> matches the beginning of the line, but doesn't eat any characters. Similarly, the word boundary anchor C<\b> matches wherever a character matching C<\w> is next to a character that doesn't, but it doesn't eat up any -characters itself. Anchors are examples of I<zero-width assertions>. -Zero-width, because they consume +characters itself. Anchors are examples of I<zero-width assertions>: +zero-width, because they consume no characters, and assertions, because they test some property of the string. In the context of our walk in the woods analogy to regexp matching, most regexp elements move us along a trail, but anchors have @@ -2384,7 +2384,7 @@ integer in parentheses C<(integer)>. It is true if the corresponding backreference C<\integer> matched earlier in the regexp. The same thing can be done with a name associated with a capture group, written as C<< (<name>) >> or C<< ('name') >>. The second form is a bare -zero width assertion C<(?...)>, either a lookahead, a lookbehind, or a +zero-width assertion C<(?...)>, either a lookahead, a lookbehind, or a code assertion (discussed in the next section). The third set of forms provides tests that return true if the expression is executed within a recursion (C<(R)>) or is being called from some capturing group, @@ -2718,8 +2718,9 @@ detailed description. Below is just one example, illustrating the control verb C<(*FAIL)>, which may be abbreviated as C<(*F)>. If this is inserted in a regexp -it will cause to fail, just like at some mismatch between the pattern -and the string. Processing of the regexp continues like after any "normal" +it will cause it to fail, just as it would at some +mismatch between the pattern and the string. Processing +of the regexp continues as it would after any "normal" failure, so that, for instance, the next position in the string or another alternative will be tried. As failing to match doesn't preserve capture groups or produce results, it may be necessary to use this in @@ -2733,8 +2734,8 @@ combination with embedded code. The pattern begins with a class matching a subset of letters. Whenever this matches, a statement like C<$count{'a'}++;> is executed, incrementing the letter's counter. Then C<(*FAIL)> does what it says, and -the regexp engine proceeds according to the book: as long as the end of -the string hasn't been reached, the position is advanced before looking +the regexp engine proceeds according to the book: as long as the end of +the string hasn't been reached, the position is advanced before looking for another vowel. Thus, match or no match makes no difference, and the regexp engine proceeds until the entire string has been inspected. (It's remarkable that an alternative solution using something like @@ -2765,6 +2766,14 @@ performing some other processing. Both C<taint> and C<eval> pragmas are lexically scoped, which means they are in effect only until the end of the block enclosing the pragmas. + use re '/m'; # or any other flags + $multiline_string =~ /^foo/; # /m is implied + +The C<re '/flags'> pragma (introduced in Perl +5.14) turns on the given regular expression flags +until the end of the lexical scope. See C<re/"'/flags' mode"> for more +detail. + use re 'debug'; /^(.*)$/s; # output debugging info @@ -2845,7 +2854,7 @@ process: Each step is of the form S<C<< n <x> <y> >>>, with C<< <x> >> the part of the string matched and C<< <y> >> the part not yet matched. The S<C<< | 1: STAR >>> says that Perl is at line number 1 -n the compilation list above. See +in the compilation list above. See L<perldebguts/"Debugging Regular Expressions"> for much more detail. An alternative method of debugging regexps is to embed C<print> -- Perl5 Master Repository
