package IPC::Open3; use strict; no strict 'refs'; # because users pass me bareword filehandles use Exporter 'import'; use Carp; use Symbol qw(gensym qualify); our $VERSION = '1.24'; our @EXPORT = qw(open3); =head1 NAME IPC::Open3 - open a process for reading, writing, and error handling using open3() =head1 SYNOPSIS use Symbol 'gensym'; # vivify a separate handle for STDERR my $pid = open3(my $chld_in, my $chld_out, my $chld_err = gensym, 'some', 'cmd', 'and', 'args'); # or pass the command through the shell my $pid = open3(my $chld_in, my $chld_out, my $chld_err = gensym, 'some cmd and args'); # read from parent STDIN # send STDOUT and STDERR to already open handle open my $outfile, '>>', 'output.txt' or die "open failed: $!"; my $pid = open3(['&', *STDIN], ['&', $outfile], undef, 'some', 'cmd', 'and', 'args'); # write to parent STDOUT and STDERR my $pid = open3(my $chld_in, ['&', *STDOUT], ['&', *STDERR], 'some', 'cmd', 'and', 'args'); # reap zombie and retrieve exit status waitpid( $pid, 0 ); my $child_exit_status = $? >> 8; =head1 DESCRIPTION Extremely similar to C from L, C spawns the given command and provides filehandles for interacting with the command's standard I/O streams. my $pid = open3($chld_in, $chld_out, $chld_err, @command_and_args); It connects C<$chld_in> for writing to the child's standard input, C<$chld_out> for reading from the child's standard output, and C<$chld_err> for reading from the child's standard error stream. If C<$chld_err> is false, or the same file descriptor as C<$chld_out>, then C and C of the child are on the same filehandle. This means that you cannot pass an uninitialized variable for C<$chld_err> and have C auto-generate a filehandle for you, but gensym from L can be used to vivify a new glob reference; see L. The C<$chld_in> handle will have autoflush turned on. By default, the filehandles you pass in are used as output parameters. C internally creates three pipes. The write end of the first pipe and the read ends of the other pipes are connected to the command's standard input/output/error, respectively. The corresponding read and write ends are placed in the first three argument to C. The filehandle arguments can take the following forms: =over =item * An uninitialized variable (technically, either C or the empty string will work): C generates a fresh filehandle and assigns it to the argument, which must be a modifiable variable for this work (otherwise an exception will be raised). This does not work for C<$chld_err>, however: If the C<$chld_err> argument is a false value, the child's error stream is automatically redirected to its standard output. =item * An existing handle in the form of a typeglob like C<*STDIN> or C<*FOO> or a reference to such: C places the filehandle in the C slot of the typeglob, which means the corresponding bareword filehandle (like C or C) can be used for I/O from/to the child process. (If the handle is already open, it is automatically closed first.) =item * A string containing the name of a bareword handle (like C<'STDIN'> or C<'FOO'>): Such strings are resolved to typeglobs at runtime and then act like the case described above. =back However, it is possible to make C use an existing handle directly (as an input argument) and skip the creation of a pipe. To do this, the filehandle argument must have one of the following two forms: =over =item * An array reference like C<['&', $fh]>, i.e. the first element is the string C<'&'> and the second element is the existing handle to use in the child process. =item * A string of the form C<< '<&FOO' >> or C<< '>&FOO' >>, i.e. a string starting with the two characters C<< <& >> (for input) or C<< >& >> (for output), followed by the name of a bareword filehandle. (The string form cannot be used with handles stored in variables.) =back If you use this form for C<$chld_in>, the filehandle will be closed in the parent process. The filehandles may also be integers, in which case they are understood as file descriptors. C returns the process ID of the child process. It doesn't return on failure: it just raises an exception matching C. However, C failures in the child (such as no such file or permission denied), are just reported to C<$chld_err> under Windows and OS/2, as it is not possible to trap them. If the child process dies for any reason, the next write to C<$chld_in> is likely to generate a SIGPIPE in the parent, which is fatal by default, So you may wish to handle this signal. Note: if you specify C<-> as the command, in an analogous fashion to C the child process will just be the forked Perl process rather than an external command. This feature isn't yet supported on Win32 platforms. C does not wait for and reap the child process after it exits. Except for short programs where it's acceptable to let the operating system take care of this, you need to do this yourself. This is normally as simple as calling C when you're done with the process. Failing to do this can result in an accumulation of defunct or "zombie" processes. See L for more information. If you try to read from the child's stdout writer and their stderr writer, you'll have problems with blocking, which means you'll want to use C