-MO=C falls over on package <none>

[p5sagit/p5-mst-13.2.git] / pod / perldebtut.pod

diff --git a/pod/perldebtut.pod b/pod/perldebtut.pod
index b553aa4..2916897 100644 (file)
--- a/pod/perldebtut.pod
+++ b/pod/perldebtut.pod
@@ -168,7 +168,7 @@ break/watch/actions
  |[|]db_cmd  Send output to pager        ![!] syscmd Run cmd in a subprocess
  q or ^D     Quit                        R           Attempt a restart
  Data Examination:       expr     Execute perl code, also see: s,n,t expr
- x|m expr      Evals expr in array context, dumps the result or lists methods.
+ x|m expr      Evals expr in list context, dumps the result or lists methods.
  p expr        Print expression (uses script's current package).
  S [[!]pat]    List subroutine names [not] matching pattern
  V [Pk [Vars]] List Variables in Package.  Vars can be ~pattern or !pattern.
@@ -294,7 +294,7 @@ Well, this isn't very easy to read, and using the helpful manual (B<h h>), the
        8  'this'
        9  'that'     
 
-That's not much help, a couple of welcome's in there, but no indication of
+That's not much help, a couple of welcomes in there, but no indication of
 which are keys, and which are values, it's just a listed array dump and, in
 this case, not particularly helpful.  The trick here, is to use a B<reference>
 to the data structure:
@@ -327,7 +327,7 @@ our expected output:
 
 While we're here, take a closer look at the 'B<x>' command, it's really useful
 and will merrily dump out nested references, complete objects, partial objects
-- justabout whatever you throw at it:
+- just about whatever you throw at it:
 
 Let's make a quick object and x-plode it, first we'll start the the debugger:
 it wants some form of input from STDIN, so we give it something non-commital,
@@ -452,7 +452,7 @@ expected output.  This is what it does:
        
 Not very consistent!  We'll set a breakpoint in the code manually and run it
 under the debugger to see what's going on.  A breakpoint is a flag, to which
-the debugger will run without interuption, when it reaches the breakpoint, it
+the debugger will run without interruption, when it reaches the breakpoint, it
 will stop execution and offer a prompt for further interaction.  In normal
 use, these debugger commands are completely ignored, and they are safe - if a
 little messy, to leave in production code.