See the return value of open. I think on some operating systems, you can check with kill whether a process still exists under that pid:

my $pid = open ...;

kill 0 => $pid;
[download]

Also see perlport, as mentioned in kill.

Following your recommended reading, I now see that "closing any piped filehandle causes the parent process to wait for the child to finish" which solves my problem.

Thanks!

That will read until the pipe is closed, which is usually when the program ends, but it could be earlier.

close($out) (done implicitly when $out goes out of scope) will wait for the program to end. It won't cause the program to end, though.

my $child_pid = open( my $out, "-|", "some command" );
[download]

waitpid($child_pid, 0);
[download]

Use close (implicitly or explicitly) with open, not waitpid.

$ perl -E'
   open(my $pipe, "-|", "perl -e'\''sleep 5; exit 3'\''");
   say time;
   close($pipe);
   say time;
   say $?>>8;
'
1280645564
1280645569
3
[download]

Sure, close can wait for "-|". But why not waitpid?

$ perl -E'
    $pid = open(my $pipe, "-|", "perl -e'\''sleep 5; exit 3'\''");
    say time;
    waitpid($pid, 0);
    say time;
    say $?>>8;
'
1280685258
1280685263
3
[download]


waitpid is documented with:


Waits for a particular child process to terminate and returns the pid of the deceased process, or -1 if there is no such child process.

The status is returned in $? and ${^CHILD_ERROR_NATIVE}.

If I read your post correctly, you're basically wanting to issue a system command from Perl and read the output of that command back into Perl. Based on that, I personally would go with what I consider in my mind to be the "quick and dirty" method, which is to use back ticks to issue the command.

In my sample code below, I'm storing a command in $cmd and then using back ticks issue that command and store the output in $cmd_out.

use strict;

my $cmd = 'cat /proc/cpuinfo';
my $cmd_out = `$cmd`;
[download]

There's a few things to keep in mind with this method:

• Your Perl script will wait until the system command is complete before continuing.
• This only gives you STDOUT. If there's an error message sent to STDERR, that output is not captured.
• I believe that the issued command only has the same level rights as the user account used to run the Perl script.

Simple and innocent looking backticks become a nightmare once you write code for more than one system. Some problems, some general, some with your example:

• You have to work with an unknown shell. Many shells behave according to POSIX, others don't. You don't know what shell you get. You can't write reliable code this way.
• You don't know the quoting rules of the shell, because you don't know the shell. You can't reliably quote program name and program arguments. You don't even know WHEN to quote names and arguments. On Windows, things are even worse. You may end passing invalid arguments to the invoked program.
• You don't know the I/O redirection rules of the shell, because you don't know the shell. < and > are pretty universal, but 2> isn't supported everywhere (e.g. command.com doesn't know that). Don't even think about 2>&1.
• /proc/cpuinfo is Linux specific. For example, FreeBSD doesn't have /proc/cpuinfo. Don't even think about Windows.
• cat is called without a path, so you will execute the first cat program found in $ENV{'PATH'}. Maybe you execute /usr/bin/cat, the program that concatenates files and prints them to STDOUT. Maybe you execute /home/evil/hoho/cat, a program that changes the root password and spawns a telnet daemon on port 37331 before pretending to be the innocent /usr/bin/cat. No big problem as long as you invoke that cat as unprivileged user, but when run as root, you loose.
• There is no cat on a fresh Windows system. A similar command is called type and is a shell built-in. Remember that it has a different behaviour (it adds output lines, both empty and with filenames, when called with more than one argument).
• There is no need to use cat inside backticks to read a file into a scalar: open my $h,'<','/proc/cpuinfo' or die "Could not read /proc/cpuinfo: $!";my $result=do { local $/=<$h> }; close $h;.
• Neither is there a need to use cat inside backticks to read a file into an array: open my $h,'<','/proc/cpuinfo' or die "Could not read /proc/cpuinfo: $!";my @result=<$h>; close $h;.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

You have to work with an unknown shell. Many shells behave according to POSIX, others don't. You don't know what shell you get. You can't write reliable code this way.

It's sh except on Windows, and that's easy to check.

@afoken,

Thanks for expanding the list of reasons why this is not the best idea of what to do for all cases. I knew there were probably more reasons than I could think of as to why this method could lead to trouble. As I mentioned, I do consider this a "quick and dirty" method because it can lead to lots of problems if you're not careful.

So far, I've been too lazy to try to figure out how to properly use the IPC::Open3 with proper error trapping. I tried unsuccessfully a few times and then gave up and used back ticks instead. I've also been lucky enough so far to not have been bitten in the rear when I've used back ticks. :D

Also, I could be wrong, but I believe that some of your cautionary warnings about OS specific commands and syntax would apply to any method in any programming language when trying to call system commands.

And yes, I probably put up a poor example. Considering it was about 12:30 am in my time zone when I posted, I should have waited until I was thinking more straight.