+Because there are more than three arguments to open(), forks the ps(1)
+command I<without> spawning a shell, and reads its standard output via the
+C<PS_PIPE> filehandle. The corresponding syntax to I<write> to command
+pipes is to use C<"|-"> in place of C<"-|">.
+
+This was admittedly a rather silly example, because you're using string
+literals whose content is perfectly safe. There is therefore no cause to
+resort to the harder-to-read, multi-argument form of pipe open(). However,
+whenever you cannot be assured that the program arguments are free of shell
+metacharacters, the fancier form of open() should be used. For example:
+
+ @grep_args = ("egrep", "-i", $some_pattern, @many_files);
+ open(GREP_PIPE, "-|", @grep_args)
+ || die "can't open @grep_args|: $!";
+
+Here the multi-argument form of pipe open() is preferred because the
+pattern and indeed even the filenames themselves might hold metacharacters.
+
+Be aware that these operations are full Unix forks, which means they may
+not be correctly implemented on all alien systems.
+
+=head2 Avoiding Pipe Deadlocks
+
+Whenever you have more than one subprocess, you must be careful that each
+closes whichever half of any pipes created for interprocess communication
+it is not using. This is because any child process reading from the pipe
+and expecting an EOF will never receive it, and therefore never exit. A
+single process closing a pipe is not enough to close it; the last process
+with the pipe open must close it for it to read EOF.
+
+Certain built-in Unix features help prevent this most of the time. For
+instance, filehandles have a "close on exec" flag, which is set I<en masse>
+under control of the C<$^F> variable. This is so any filehandles you
+didn't explicitly route to the STDIN, STDOUT or STDERR of a child
+I<program> will be automatically closed.
+
+Always explicitly and immediately call close() on the writable end of any
+pipe, unless that process is actually writing to it. Even if you don't
+explicitly call close(), Perl will still close() all filehandles during
+global destruction. As previously discussed, if those filehandles have
+been opened with Safe Pipe Open, this will result in calling waitpid(),
+which may again deadlock.