All of the following will do the trick:

• IPC::Run
• IPC::Open3 (Core module written to address this issue.)
• IPC::Open2 (Core module written to address this issue.)
• fork+exec (Inefficient in Windows)
• system 1, ... (Only on Windows)
• system "start ..." (Only on Windows. Has security issues from loading shell)
• system "... &" (Only on unix. Has security issues from loading shell)

Has security issues from loading shell

Could you explain, or provide a pointer to discussion of the security issues?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Due care must be spent on sanitizing and escaping the arguments if they are not hard coded.

$file_name = 'file name';
system("program $file_name &");  # Oops!
[download]

Without due care, the code may not work, or worse, it could be vulnerable to injection attacks.

Also IPC::Run3

...
# time to start a separate process, but we want the parent to keep run
+ning
# (i.e. parent and child run simultaneously)

my $childpid = fork();
if ( !defined( $childpid )) {
    die "couldn't fork: $!";
} 
elsif ( $childpid == 0 ) {  # this is what the child does:
    exec( "other_program", @args );
    # at this point, the other_program is running; it replaces
    # (has the same pid that was originally assigned to) the
    # "child copy" of the current script
}
# and here, the parent continues what it was doing...
[download]

But as you have seen, it also works to simply include the ampersand at the end of the command line passed to "system()".

a call to exit() should be included after the exec() so that in case the exec fails, the child doesn't continue running parent code.

These programs are different so I don't see using fork() as something viable.