open statement can also be used for
unidirectional interprocess communication by either appending or prepending
a pipe symbol to the second argument to open. Here's how to
start something up in a child process you intend to write to:
open(SPOOLER, "| cat -v | lpr -h 2>/dev/null")
|| die "can't fork: $!";
local $SIG{PIPE} = sub { die "spooler pipe broke" };
print SPOOLER "stuff\n";
close SPOOLER || die "bad spool: $! $?";
And here's how to start up a child process you intend to read from:
open(STATUS, "netstat -an 2>&1 |")
|| die "can't fork: $!";
while (<STATUS>) {
next if /^(tcp|udp)/;
print;
}
close STATUS || die "bad netstat: $! $?";
If one can be sure that a particular program is a Perl script that is expecting filenames in @ARGV, the clever programmer can write something like this:
$ program f1 "cmd1|" - f2 "cmd2|" f3 < tmpfile
and irrespective of which shell it's called from, the Perl program will read from the file f1, the process cmd1, standard input (tmpfile in this case), the f2 file, the cmd2 command, and finally the f3 file. Pretty nifty, eh?
You might notice that you could use back-ticks for much the same effect as opening a pipe for reading:
print grep { !/^(tcp|udp)/ } `netstat -an 2>&1`;
die "bad netstat" if $?;
While this is true on the surface, it's much more efficient to process the file one line or record at a time because then you don't have to read the whole thing into memory at once. It also gives you finer control of the whole process, letting you to kill off the child process early if you'd like.
Be careful to check both the open and the close
return values. If you're writing to a pipe, you should also trap
SIGPIPE. Otherwise, think of what happens when you
start up a pipe to a command that doesn't exist: the open will
in all likelihood succeed (it only reflects the fork's
success), but then your output will fail--spectacularly. Perl can't know
whether the command worked because your command is actually running in a
separate process whose exec might have failed. Therefore,
while readers of bogus commands return just a quick end of file, writers to
bogus command will trigger a signal they'd better be prepared to handle.
Consider:
open(FH, "|bogus");
print FH "bang\n";
close FH;