Problem

You want to run another program from your own, pause until the other program is done, and then continue. The other program should have same STDIN and STDOUT as you have.

Solution

Call system with a string to have the shell interpret the string as a command line:

$status = system("vi $myfile");

If you don't want the shell involved, pass system a list:

$status = system("vi", $myfile);

Discussion

The system function is the simplest and most generic way to run another program in Perl. It doesn't gather the program's STDOUT like backticks or open. Instead, its return value is (essentially) that program's exit status. While the new program is running, your main program is suspended, so the new program can read from your STDIN and write to your STDOUT so users can interact with it.

Like open, exec, and backticks, system uses the shell to start the program whenever it's called with one argument. This is convenient when you want to do redirection or other tricks:

system("cmd1 args | cmd2 | cmd3 >outfile");
system("cmd args <infile >outfile 2>errfile");

To avoid the shell, call system with a list of arguments:

$status = system($program, $arg1, $arg);
die "$program exited funny: $?" unless $status == 0;

The returned status value is not just the exit value: it includes the signal number (if any) that the process died from. This is the same value that wait sets $? to. See Recipe 16.19 to learn how to decode this value.

The system function (but not backticks) ignores SIGINT and SIGQUIT while child processes are running. That way those signals will kill only the child process. If you want your main program to die as well, check the return value of system, or the value of the $? variable.

if (($signo = system(@arglist)) &= 127) { 
    die "program killed by signal $signo\n";
}

To get the effect of a system that ignores SIGINT, install your own signal handler and then manually fork and exec:

if ($pid = fork) {
    # parent catches INT and berates user
    local $SIG{INT} = sub { print "Tsk tsk, no process interruptus\n" };
    waitpid($pid, 0);
} else {
    die "cannot fork: $!" unless defined $pid;
    # child ignores INT and does its thing
    $SIG{INT} = "IGNORE";
    exec("summarize", "/etc/logfiles")             or die "Can't exec: $!\n";
}

A few programs examine their own program name. Shells look to see whether they were called with a leading minus to indicate interactivity. The expn program at the end of Chapter 18 behaves differently if called as vrfy, which can happen if you've installed the file under two different links as suggested. This is why you shouldn't trust that $0 is really the pathname to the invoked program - you could have been lied to in a number of ways.

If you want to fib to the program you're executing about its own name, specify the real path as the "indirect object" in front of the list passed to system. (This also works with exec.) The indirect object has no comma following it, just like using printf with a filehandle or making object methods without the pointer arrow.

$shell = '/bin/tcsh';
system $shell '-csh';           # pretend it's a login shell

Or, more directly:

system {'/bin/tcsh'} '-csh';    # pretend it's a login shell

In the next example, the program's real pathname is supplied in the indirect object slot as {'/home/tchrist/scripts/expn'}. The fictitious name 'vrfy' is given as the first real function argument, which the program will see stored in $0.

# call expn as vrfy
system {'/home/tchrist/scripts/expn'} 'vrfy', @ADDRESSES;

Using an indirect object with system is also more secure. This usage forces interpretation of the arguments as a multivalued list, even if the list had just one argument. That way you're safe from the shell expanding wildcards or splitting up words with whitespace in them.

@args = ( "echo surprise" );

system @args;               # subject to shell escapes if @args == 1
system { $args[0] } @args;  # safe even with one-arg list

The first version, the one without the indirect object, ran the echo program, passing it "surprise" an argument. The second version didn't - it tried to run a program literally called "echo surprise", didn't find it, and set $? to a non-zero value indicating failure.

See Also

The section on "Cooperating with Strangers" in Chapter 6 of Programming Perl, or perlsec (1); the waitpid, fork, exec, system, and open functions in Chapter 3 of Programming Perl or perlfunc (1); Recipe 16.1; Recipe 16.4; Recipe 16.19; Recipe 19.6; Advanced Programming in the UNIX Environment, by Richard W. Stevens; Addison-Wesley (1992)