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);
  }
[download]

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.