cvs commit: perlfaq perlfaq8.pod

cvsuser     02/04/18 07:23:15

  Modified:    .        perlfaq8.pod
  Log:
  faq sync:
  
  * Why doesn't open() return an error when a pipe open fails?
  -- added comments on checking for failure
  
  * What's wrong with using backticks in a void context?
  -- backticks are no longer inefficient in void context, but
  why use them that way, regardless?
  
  Revision  Changes    Path
  1.7       +24 -36    perlfaq/perlfaq8.pod
  
  Index: perlfaq8.pod
  ===================================================================
  RCS file: /cvs/public/perlfaq/perlfaq8.pod,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -w -r1.6 -r1.7
  --- perlfaq8.pod	28 Jan 2002 04:17:27 -0000	1.6
  +++ perlfaq8.pod	18 Apr 2002 14:23:15 -0000	1.7
  @@ -1,6 +1,6 @@
   =head1 NAME
   
  -perlfaq8 - System Interaction ($Revision: 1.6 $, $Date: 2002/01/28 04:17:27 $)
  +perlfaq8 - System Interaction ($Revision: 1.7 $, $Date: 2002/04/18 14:23:15 $)
   
   =head1 DESCRIPTION
   
  @@ -680,50 +680,38 @@
   
   =head2 Why doesn't open() return an error when a pipe open fails?
   
  -Because the pipe open takes place in two steps: first Perl calls
  -fork() to start a new process, then this new process calls exec() to
  -run the program you really wanted to open.  The first step reports
  -success or failure to your process, so open() can only tell you
  -whether the fork() succeeded or not.
  -
  -To find out if the exec() step succeeded, you have to catch SIGCHLD
  -and wait() to get the exit status.  You should also catch SIGPIPE if
  -you're writing to the child--you may not have found out the exec()
  -failed by the time you write.  This is documented in L<perlipc>.
  -
  -In some cases, even this won't work.  If the second argument to a
  -piped open() contains shell metacharacters, perl fork()s, then exec()s
  -a shell to decode the metacharacters and eventually run the desired
  -program.  Now when you call wait(), you only learn whether or not the
  -I<shell> could be successfully started...it's best to avoid shell
  -metacharacters.
  -
  -On systems that follow the spawn() paradigm, open() I<might> do what
  -you expect--unless perl uses a shell to start your command. In this
  -case the fork()/exec() description still applies.
  +If the second argument to a piped C<open> contains shell
  +metacharacters, perl fork()s, then exec()s a shell to decode the
  +metacharacters and eventually run the desired program.  If the program
  +couldn't be run, it's the shell that gets the message, not Perl. All
  +your Perl program can find out is whether the shell itself could be
  +successfully started.  You can still capture the shell's STDERR and
  +check it for error messages.  See L<"How can I capture STDERR from an
  +external command?"> elsewhere in this document, or use the
  +L<IPC::Open3> module.
  +
  +If there are no shell metacharacters in the argument of C<open>, Perl
  +runs the command directly, without using the shell, and can correctly
  +report whether the command started.
   
   =head2 What's wrong with using backticks in a void context?
   
   Strictly speaking, nothing.  Stylistically speaking, it's not a good
  -way to write maintainable code because backticks have a (potentially
  -humongous) return value, and you're ignoring it.  It's may also not be very
  -efficient, because you have to read in all the lines of output, allocate
  -memory for them, and then throw it away.  Too often people are lulled
  -to writing:
  -
  -    `cp file file.bak`;
  -
  -And now they think "Hey, I'll just always use backticks to run programs."
  -Bad idea: backticks are for capturing a program's output; the system()
  -function is for running programs.
  +way to write maintainable code.  Perl has several operators for
  +running external commands.  Backticks are one; they collect the output
  +from the command for use in your program.  The C<system> function is
  +another; it doesn't do this.  
  +
  +Writing backticks in your program sends a clear message to the readers
  +of your code that you wanted to collect the output of the command.
  +Why send a clear message that isn't true?
   
   Consider this line:
   
       `cat /etc/termcap`;
   
  -You haven't assigned the output anywhere, so it just wastes memory
  -(for a little while).  You forgot to check C<$?> to see whether
  -the program even ran correctly, too.  Even if you wrote
  +You forgot to check C<$?> to see whether the program even ran
  +correctly.  Even if you wrote
   
       print `cat /etc/termcap`;