This is my patch patch.1g for perl5.001.

[p5sagit/p5-mst-13.2.git] / lib / IPC / Open2.pm

diff --git a/lib/IPC/Open2.pm b/lib/IPC/Open2.pm
index c59c7d6..71f89f3 100644 (file)
--- a/lib/IPC/Open2.pm
+++ b/lib/IPC/Open2.pm
@@ -3,6 +3,51 @@ require 5.000;
 require Exporter;
 use Carp;
 
+=head1 NAME
+
+IPC::Open2, open2 - open a process for both reading and writing
+
+=head1 SYNOPSIS
+
+    use IPC::Open2;
+    $pid = open2('rdr', 'wtr', 'some cmd and args');
+      # or
+    $pid = open2('rdr', 'wtr', 'some', 'cmd', 'and', 'args');
+
+=head1 DESCRIPTION
+
+The open2() function spawns the given $cmd and connects $rdr for
+reading and $wtr for writing.  It's what you think should work 
+when you try
+
+    open(HANDLE, "|cmd args");
+
+open2() returns the process ID of the child process.  It doesn't return on
+failure: it just raises an exception matching C</^open2:/>.
+
+=head1 WARNING 
+
+It will not create these file handles for you.  You have to do this yourself.
+So don't pass it empty variables expecting them to get filled in for you.
+
+Additionally, this is very dangerous as you may block forever.
+It assumes it's going to talk to something like B<bc>, both writing to
+it and reading from it.  This is presumably safe because you "know"
+that commands like B<bc> will read a line at a time and output a line at
+a time.  Programs like B<sort> that read their entire input stream first,
+however, are quite apt to cause deadlock.  
+
+The big problem with this approach is that if you don't have control 
+over source code being run in the the child process, you can't control what it does 
+with pipe buffering.  Thus you can't just open a pipe to "cat -v" and continually
+read and write a line from it.
+
+=head1 SEE ALSO
+
+See L<open3> for an alternative that handles STDERR as well.
+
+=cut
+
 @ISA = qw(Exporter);
 @EXPORT = qw(open2);