16.8.3. Discussion

Wanting simultaneous read and write access to another program is very common, but surprisingly perilous. That's one reason the built-in open doesn't permit:

open(my $double_handle, "| program args |")     # WRONG

The big problem here is buffering. Because you can't force the other program to unbuffer its output, you can't guarantee that your reads won't block. If you block trying to read at the same time the other process blocks waiting for you to send something, you've achieved the unholy state of deadlock. There you'll both stay, wedged, until someone kills your process or the machine reboots.

If you control the other process's buffering because you wrote the other program and know how it works, then IPC::Open2 may be the module for you. If you pass undefined scalar values as the first two arguments, open2 creates new filehandles:

use IPC::Open2;

$pid = open2(my $reader, my $writer, $program);

Alternatively, you can pass in arguments that look like "<&OTHERFILEHANDLE" or ">&OTHERFILEHANDLE", which specify existing filehandles for the child process to read from or write to. These filehandles don't have to be controlled by your program—they may be connected to other programs, files, or sockets.

You can specify the program either as a list (where the first element is the program name and the remaining elements are arguments to the program) or as a single string (which is passed to the shell as a command to start the program). If you also want control over the process's standard error, use the IPC::Open3 module and see the next recipe.

If an error occurs, open2 and open3 do not return. Instead, they die with an error message that begins with "open2" or "open3". To test for failure, use the eval BLOCK construct:

eval {
    $pid = open2($readme, $writeme, @program_and_arguments);
};
if ($@) { 
    if ($@ =~ /^open2/) {
        warn "open2 failed: $!\n$@\n";
        return;
    }
    die;            # reraise unforeseen exception
}

You must call waitpid, as we do in the Solution, because IPC::Open2 doesn't reap the child process after it exits. See Recipe 16.19 for details.