Document what the backtick returns if the command fails.

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

diff --git a/pod/perlsub.pod b/pod/perlsub.pod
index 927e944..9976316 100644 (file)
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -39,7 +39,7 @@ To call subroutines:
 Like many languages, Perl provides for user-defined subroutines.
 These may be located anywhere in the main program, loaded in from
 other files via the C<do>, C<require>, or C<use> keywords, or
-generated on the fly using C<eval> or anonymous subroutines (closures).
+generated on the fly using C<eval> or anonymous subroutines.
 You can even call a function indirectly using a variable containing
 its name or a CODE reference.
 
@@ -154,7 +154,7 @@ of changing them in place:
     }
 
 Notice how this (unprototyped) function doesn't care whether it was
-passed real scalars or arrays.  Perl sees all arugments as one big,
+passed real scalars or arrays.  Perl sees all arguments as one big,
 long, flat parameter list in C<@_>.  This is one area where
 Perl's simple argument-passing style shines.  The C<upcase()>
 function would work perfectly well without changing the C<upcase()>
@@ -179,7 +179,7 @@ when just naming the subroutine, such as when it's used as
 an argument to defined() or undef().  Nor is it optional when you
 want to do an indirect subroutine call with a subroutine name or
 reference using the C<&$subref()> or C<&{$subref}()> constructs,
-although the C<$subref-E<gt>()> notation solves that problem.
+although the C<< $subref->() >> notation solves that problem.
 See L<perlref> for more about all that.
 
 Subroutines may be called recursively.  If a subroutine is called
@@ -357,7 +357,7 @@ A compilation error results otherwise.  An inner block may countermand
 this with C<no strict 'vars'>.
 
 A C<my> has both a compile-time and a run-time effect.  At compile
-time, the compiler takes notice of it.  The principle usefulness
+time, the compiler takes notice of it.  The principal usefulness
 of this is to quiet C<use strict 'vars'>, but it is also essential
 for generation of closures as detailed in L<perlref>.  Actual
 initialization is delayed until run time, though, so it gets executed
@@ -891,7 +891,7 @@ like a built-in function.  If you call it like an old-fashioned
 subroutine, then it behaves like an old-fashioned subroutine.  It
 naturally falls out from this rule that prototypes have no influence
 on subroutine references like C<\&foo> or on indirect subroutine
-calls like C<&{$subref}> or C<$subref-E<gt>()>.
+calls like C<&{$subref}> or C<< $subref->() >>.
 
 Method calls are not influenced by prototypes either, because the
 function to be called is indeterminate at compile time, since
@@ -1270,7 +1270,7 @@ see L<attributes>.
 
 See L<perlref/"Function Templates"> for more about references and closures.
 See L<perlxs> if you'd like to learn about calling C subroutines from Perl.  
-See L<perlembed> if you'd like to learn about calling PErl subroutines from C.  
+See L<perlembed> if you'd like to learn about calling Perl subroutines from C.  
 See L<perlmod> to learn about bundling up your functions in separate files.
 See L<perlmodlib> to learn what library modules come standard on your system.
 See L<perltoot> to learn how to make object method calls.