[perl #99382] 'stat' call documentation is poorly worded

[perl5.git] / pod / perldebguts.pod

diff --git a/pod/perldebguts.pod b/pod/perldebguts.pod
index 9bc0b63..fdddf4a 100644 (file)
--- a/pod/perldebguts.pod
+++ b/pod/perldebguts.pod
@@ -38,7 +38,6 @@ Each array C<@{"_<$filename"}> holds the lines of $filename for a
 file compiled by Perl.  The same is also true for C<eval>ed strings
 that contain subroutines, or which are currently being executed.
 The $filename for C<eval>ed strings looks like C<(eval 34)>.
-Code assertions in regexes look like C<(re_eval 19)>.
 
 Values in this array are magical in numeric context: they compare
 equal to zero only if the line is not breakable.
@@ -53,14 +52,14 @@ C<"$break_condition\0$action">.
 
 The same holds for evaluated strings that contain subroutines, or
 which are currently being executed.  The $filename for C<eval>ed strings
-looks like C<(eval 34)> or C<(re_eval 19)>.
+looks like C<(eval 34)>.
 
 =item *
 
 Each scalar C<${"_<$filename"}> contains C<"_<$filename">.  This is
 also the case for evaluated strings that contain subroutines, or
 which are currently being executed.  The $filename for C<eval>ed
-strings looks like C<(eval 34)> or C<(re_eval 19)>.
+strings looks like C<(eval 34)>.
 
 =item *
 
@@ -81,7 +80,7 @@ also exists.
 A hash C<%DB::sub> is maintained, whose keys are subroutine names
 and whose values have the form C<filename:startline-endline>.
 C<filename> has the form C<(eval 34)> for subroutines defined inside
-C<eval>s, or C<(re_eval 19)> for those within regex code assertions.
+C<eval>s.
 
 =item *
 
@@ -227,7 +226,7 @@ information.  For example, contrast this expression trace:
  Loading DB routines from perl5db.pl patch level 0.94
  Emacs support available.
 
- Enter h or `h h' for help.
+ Enter h or 'h h' for help.
 
  main::(-e:1):   0
    DB<1> sub foo { 14 }
@@ -412,7 +411,7 @@ scoped.
 
 The debugging output at compile time looks like this:
 
-  Compiling REx `[bc]d(ef*g)+h[ij]k$'
+  Compiling REx '[bc]d(ef*g)+h[ij]k$'
   size 45 Got 364 bytes for offset annotations.
   first at 1
   rarest char g at 0
@@ -433,8 +432,8 @@ The debugging output at compile time looks like this:
     42: EXACT <k>(44)
     44: EOL(45)
     45: END(0)
-  anchored `de' at 1 floating `gh' at 3..2147483647 (checking floating) 
-        stclass `ANYOF[bc]' minlen 7 
+  anchored 'de' at 1 floating 'gh' at 3..2147483647 (checking floating) 
+        stclass 'ANYOF[bc]' minlen 7 
   Offsets: [45]
        1[4] 0[0] 0[0] 0[0] 0[0] 0[0] 0[0] 0[0] 0[0] 0[0] 0[0] 5[1]
        0[0] 12[1] 0[0] 6[1] 0[0] 7[1] 0[0] 9[1] 8[1] 0[0] 10[1] 0[0]
@@ -450,8 +449,8 @@ label I<id> of the first node that does a match.
 
 The 
 
-  anchored `de' at 1 floating `gh' at 3..2147483647 (checking floating) 
-        stclass `ANYOF[bc]' minlen 7 
+  anchored 'de' at 1 floating 'gh' at 3..2147483647 (checking floating) 
+        stclass 'ANYOF[bc]' minlen 7 
 
 line (split into two lines above) contains optimizer
 information.  In the example shown, the optimizer found that the match 
@@ -520,7 +519,7 @@ being C<BOL>, C<MBOL>, or C<GPOS>.  See the table below.
 =back
 
 If a substring is known to match at end-of-line only, it may be
-followed by C<$>, as in C<floating `k'$>.
+followed by C<$>, as in C<floating 'k'$>.
 
 The optimizer-specific information is used to avoid entering (a slow) regex
 engine on strings that will not definitely match.  If the C<isall> flag
@@ -805,7 +804,7 @@ entered and that all of the job was therefore done by the optimizer.
 
 If the regex engine was entered, the output may look like this:
 
-  Matching `[bc]d(ef*g)+h[ij]k$' against `abcdefg__gh__'
+  Matching '[bc]d(ef*g)+h[ij]k$' against 'abcdefg__gh__'
     Setting an EVAL scope, savestack=3
      2 <ab> <cdefg__gh_>    |  1: ANYOF
      3 <abc> <defg__gh_>    | 11: EXACT <d>