Errata

I'm using the ePub version with the iBooks app on an iPad Air. The contents page reacts extremely slowly (clicking on an entry takes 15-20 seconds until the linked page shows up). Opening the contents page from the book may also have massive delays. Scrolling works fine in the contents, though. Turning pages in the book itself works fine as well.

This behaviour does not always happen right from the start, sometimes I need to click two or three links in the contents before it becomes slow. Once slow, it remains slow.
I have not experienced this with other ePub ebooks, therefore I assume this is a problem with the book itself.

The Perl solution is listed as
$`$_$'

It kind of works, but not as how it is explained.
It will do the substiution correctly like so:

$_ = 'BeforeMatchAfter';
s/Match/$`$_$'/;

However, the explanation is wrong about $_. It is not set to anything after a match (whether in m/ or s//). In the code above, it is assigned the value of the subject string. It has the same value in the replacement part, so the code has the intended effect.
-----------------------------------------------------------------------------------------------
However, if you tried this, it would not work as intended:

$subject = 'BeforeMatchAfter';
$subject =~ s/Match/$`$_$'/;

This would put the value of $_ - whatever it was BEFORE those 2 statements - into the middle of the modified subject string.

----------------------------------------------------------------------------
It is actually $$ that is set to the value of the match, so the general solution is:
$subject = 'BeforeMatchAfter';
$subject =~ s/Match/$`$`$&$'$'/;

$& gets "Match" ONLY, so another $` and $' must be put in the replacement string to get the string changed to "BeforeBeforeBeforeMatchAfterAfterAfter"

"Discussion:

End of the subject
The difference between ‹\Z› and ‹\z› comes into play when the last
character in your subject text is a line break. In that case,
‹\Z› can match at the very end of the subject text, after the final
line break, as well as immediately before that line break.
.
.
.
The anchor ‹$› is equivalent to ‹\Z›, as long as you do not turn on
the “^ and $ match at line breaks” option.

End of a line
By default, ‹$› matches only at the end of the subject text
or before the final line break, just like ‹\Z›."


These statements are not correct in regards to Python's \Z anchor, which acts
like the \z anchor in other languages. The following program demonstrates this:


import re

if re.search('foo$', 'foo'): print('foo matched with $')
if re.search('foo\Z', 'foo'): print('foo matched with \Z')
if re.search('foo$', 'foo\n'): print('foo\\n matched with $')
if re.search('foo\Z', 'foo\n'): print("foo\\n matched with \Z")

The last sentence in the 'Perl and Ruby' paragraph states:
"we can easily retrieve the text between the match and the previous one with $`"

This is incorrect, I believe, at least according to my tests and what Jeffrey Friedl says in 'Mastering Regular Expressions, 3rd edtion', page 300: "you might wish $` to be the text from start of the match attempt, but it's the text from the start of the whole string, each time."

The code in your Perl example still works because the substitution across the entire string from the beginning to the previous match has already been done and so the code would simply ignore those quotes already changed.

Nonetheless, I believe it is a misunderstanding to think that $` is that part of the string since the last match, which could cause serious issues in cases where someone really doesn't want their code to re-iterate over the beginning of the string again... perhaps changing items numerous times...

Please let me know if I have misunderstood your point above or the issue. Thanks!

The Perl solution does not work as intended. The mistake was to assume that using "/g" on a match affects where $` begins. It doesn't; $` captures all of the string before the match, regardless of what pos() would have returned before.

Here is a Perl program that has been confirmed to solve the problem:

$result ="";
$textafter = $subject = '"text" <span class="middle">"text"</span> "text"';


while ($textafter =~ m/<[^<>]*>/) {
$match = $&;
$textafter = $';
($textbetween = $`) =~ s/"([^"]*)"/\x{201C}$1\x{201D}/;
$result .= $textbetween . $match;
}
$textafter =~ s/"([^"]*)"/\x{201C}$1\x{201D}/;
$result .= $textafter;

The following regular expression is the first solution in 4.2. It is supposed to match valid North American phone numbers (while ignoring some restrictions later discussed):

^\(?([0-9]{3})\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$

It matches several bad forms, including
(2135551212
(714)-555-1212
310)555 1212


A Perl regex and substitution that matches the valid forms listed in the text, while excluding those that don't handle the optional parentheses correctly, is:

s#^(?<p>\()?(?<a>[0-9]{3})(?(<p>)\) ?|[-. ]?)(?<e>[0-9]{3})[-. ]?(?<n>[0-9]{4})$#($+{a}) $+{e}-$+{n}#

All three of these recipes for matching comments -- single-line comments, multiline comments, and all comments -- have the same flaw. They produce a false positive match when the comment symbols appear within a string, such as:

echo "// hello";

so these simple regex solutions can't be used for processing real source code.

This shortcoming should at least be mentioned explicitly in the recipes, even if you decide not to change the solutions.

The interaction between string and comment syntax is quite interesting and would make a good recipe on its own. Not only can strings include comment symbols, but comments can include single and double quotes.

Footnote 2:

If there are n characters between the double quote and the end of the string, the regex engine will
try 2 1/n permutations of ? (?:[^"\r\n]+|"")* ?

----

it appears: 2^(1/n)
(this trends to 1, when n grows)

however, it must say 2^(n-1)
when n=4 the number of permutations is 8.
(thus, it has an exponential behavior).

"\b is needed between \w and \W ... to ensure that each repetition of the group really matches an entire word"

This is not only false in this specific case, as can be seen by experimenting with code like the Python and Perl statements below. The word boundary \b is never needed between any forms of the pair of character classes \w and \W. It is entirely redundant.
------------------------------------------------
print "match\n" if 'fee fi fo fum ' =~ /^W*(?:\w+\b\W*){1,4}$/;

-------------------------------------------------
use re
if re.search("^\W*(?:\w+\W*){1,4}$", 'fee fi fo fum ') : print ("match")

The regular expression is missing the asterisk just before the final double quotes.
It should be:
"[^"\\\r\n]*(?:\\.[^"\\\r\n]*)*"