Perl Cd Bookshelf [Electronic resources] نسخه متنی

16.2. Running Another Program

From one program you want to run
another, pause until it is done, and then continue with the original
program. The other program should have the same
STDIN and STDOUT as you have.

16.2.2. 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);

16.2.3. 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 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" as 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.

16.2.4. See Also

The section on "Talking to Yourself" in Chapter 16 of
Programming Perl or
perlsec(1); the waitpid,
fork, exec,
system, and open functions in
Chapter 29 of Programming Perl, or
perlfunc(1); Recipe 16.1; Recipe 16.4; Recipe 16.19; Recipe 19.5;
Advanced Programming in the UNIX Environment,
by Richard W. Stevens (Addison-Wesley)

16.1. Gathering Output from a Program		16.3. Replacing the Current Program with a Different One

Copyright © 2003 O'Reilly & Associates. All rights reserved.