http://qs321.pair.com?node_id=198946


in reply to Working with other processes and programs

Here are a few additional related details:

My pid is in $$ or is returned by getpgrp(0)

My parent's pid is getppid()

Launching a process and *not* waiting is done with fork but read the fork docs before using it because it doesn't work like you might expect... Using open instead of fork is probably a better choice much of the time.

Closing the opened handle without reading the output dumps the output to stdout. (this could be implementation specific??)

You can get the exit code of the child process from $? >>8

Linuxboy

  • Comment on Re: Working with other processes and programs

Replies are listed 'Best First'.
Re^2: Working with other processes and programs
by DeadPoet (Scribe) on Jan 09, 2011 at 15:49 UTC
    Other thoughts to consider when evaluating return codes can include how the process was created. For example, if one uses the IPC::Open3 module to run the external command and the processes (pid) is killed using 'kill( 9, $pid )' the '$? >> 8' evaluation may result in 0. This is probably not the expected value, seeing how the processes was terminated. However, if one inspects the '${^CHILD_ERROR_NATIVE}' the result would show an exit value of 9.

    According to PerlDoc:

    If the filehandle came from a piped open, close returns false if one of the other syscalls involved fails or if its program exits with non-zero status. If the only problem was that the program exited non-zero, $! will be set to 0. Closing a pipe also waits for the process executing on the pipe to exit--in case you wish to look at the output of the pipe afterwards--and implicitly puts the exit status value of that command into $? and ${^CHILD_ERROR_NATIVE}.

    http://search.cpan.org/~jesse/perl-5.12.2/pod/perlfunc.pod

    Admittedly this may be a result of how things are terminated, closed and cleaned up. But it is a thought to consider.

[reply]

In Section Tutorials