open-coding a system() operation

[merlyn]

Sometimes, you want a system(), but you want the child to have a different current directory, environment, Standard Input/Output/Error, or whatever normally gets inherited by a fork. The trick is to emulate the system() with slightly lower-level calls, and then insert your code for changes where only the child executes it. Here's a sample skeleton (from when I was answering a question).

# replacing system("date") with:
defined(my $pid = fork) or die "Cannot fork: $!";
unless($pid) { # I'm the child
  # make your env changes here
  # you can also change directory, umask, priority, etc.
  exec "date";
  die "date not found (just like me last friday night)";
}
# parent continues here...
{
  # to emulate system(), we need to ignore INT and QUIT
  # while the kid is foreground
  local $SIG{INT} = local $SIG{QUIT} = 'IGNORE';
  waitpid($pid, 0);
}

[Juerd]

I usually use if/elsif/else when forking:

if (my $pid = fork) {
    # Parent
    local $SIG{INT}  = 'IGNORE';
    local $SIG{QUIT} = 'IGNORE';
    waitpid($pid, 0);
} elsif (defined $pid) {
    # Child
    exec 'date';
    die 'date not found'
} else {
    die "Can't fork: $!";
}

Which is the same thing, but in my opinion a little easier to read.

Why do you ignore those signals? I know near to nothing about signals and would like to learn (have only used HUP to reload configuration files, and Perl's __DIE__/__WARN__).

Juerd
- http://juerd.nl/
- [e-mail] (do not use).

[merlyn]

I ignore the signals because Perl does. Perl emulates the system(3) call from C, which also ignores those signals. That's so you can press ^C while system is running a vi for you, and stop the vi without killing the Perl that is also running.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

[dug]

I've written this both ways before, but generally prefer the style that merlyn used in the snippet. I like to see potential failures at the beginning of a block of code if it makes sense (it does to me in this snippet). It also fits my brain best to see the child before the parent, since it will most likely be doing the heavy lifting.

After all this talk of child labor is reminding me of William Blake's "The Chimney Sweeper". Guess I have my night reading lined out for me ;-)

-- dug

[Anonymous Monk]

I've often found for what I'm using system() for that the implicit fork inherent in a open(CHILD, "|-") is a useful way to go. I get the fork plus control over the child's STDIN in one shot. I also get an automatic waitpid call when I close the parent side. For example, culled from production code in a case where we don't want the child process to have any possible way to be still talking to the controlling terminal:

  # my $status = system($command);
  # Our better version of system()
  my $status;
  my $pid = open(KID_STDIN, "|-");
  if (not defined $pid) {
    die "cannot fork: $!; bailing out";
  }
  if ($pid) { ## parent
    close(KID_STDIN);
    $status = $?;
  } else {
    POSIX::setsid(); # disconnect from controlling terminal
    open(STDOUT, ">> $_LogFileName");
    open(STDERR, '>&STDOUT');
    exec($command);
  }

In the specific example here, we're using system to run java programs which read from data files given as parameters and produce log output on STDOUT, with exceptional output (such as an uncaught runtime exception that produces a stacktrace) going to STDERR. Because java plays games with its signal handlers, we discovered that running the driver perl script under "nohup" did not in fact allow us to start the driver script up and let it run in the background - java would still abort when the initial xterm was closed. Rewriting system() to include the setsid call finally fixed that problem.