You're sort of close -- you just have some confusion about which things should be done by the child as opposed to being done by the parent.

The section of the perlipc manual pointed to by runrig above is for a slightly different situation: starting a perl script as a "daemon" process that is supposed to run continuously, operating as a service that other processes can connect to (usually via sockets) for transactions.

In your case, I would assume that the process to be launched will accomplish some particular task and then exit (go away) when it's done. So a lot of the care and special steps involved in "daemonizing" a process would probably not apply here, or would be applied differently.

For example, you might want STDOUT and/or STDERR for the child process to be redirected to a log file somewhere, and chdir "/" might be unnecessary or inappropriate.

In any case, you do not want to redirect STDOUT or STDERR in the parent: STDOUT needs to go back to the web client, and STDERR should go to the web server's error log. Also, since you are doing a "fork", the child should do an "exec" -- something like this, most likely:

my $pid = fork();

my $report;
if (not defined $pid) {
    $report = "We were unable to process your file.\n";
    warn "$0: $!\n";   # put something in the web server errlog
}
elsif ($pid == 0) {
    # child process: launch the other executable
    open STDOUT, ">>", "/some/path/myfile.log";
    open STDERR, ">>", "/some/path/myfile.err";
    exec("/usr/local/bin/launch myfile");
}
else {
    # parent process: report the child process was launched
    $report = "Your file has been sent successfully.  You will be noti
+fied via email once it has been completed.  Thank you.";
}
print $report, end_html();
[download]

(I haven't tested that, but I'm pretty sure when "exec" invokes the process that you pass to it, that process inherits the current STDOUT and STDERR.)