How can I run Perl system commands in the background?

Question

#!/usr/bin/env perl
use warnings; use strict;
use 5.012;
use IPC::System::Simple qw(system);

system( \'xterm\', \'-geometry\', \'80x25-5-5\', \'-bg\', \'green\', \'         


        

Answer 1

Note that the list form of system is specifically there to not treat characters such as & as shell meta-characters.

From perlfaq8's answer to How do I start a process in the background?

---

(contributed by brian d foy)

There's not a single way to run code in the background so you don't have to wait for it to finish before your program moves on to other tasks. Process management depends on your particular operating system, and many of the techniques are in perlipc.

Several CPAN modules may be able to help, including IPC::Open2 or IPC::Open3, IPC::Run, Parallel::Jobs, Parallel::ForkManager, POE, Proc::Background, and Win32::Process. There are many other modules you might use, so check those namespaces for other options too.

If you are on a Unix-like system, you might be able to get away with a system call where you put an & on the end of the command:

system("cmd &")

You can also try using fork, as described in perlfunc (although this is the same thing that many of the modules will do for you).

STDIN, STDOUT, and STDERR are shared

Both the main process and the backgrounded one (the "child" process) share the same STDIN, STDOUT and STDERR filehandles. If both try to access them at once, strange things can happen. You may want to close or reopen these for the child. You can get around this with opening a pipe (see open in perlfunc) but on some systems this means that the child process cannot outlive the parent. Signals You'll have to catch the SIGCHLD signal, and possibly SIGPIPE too. SIGCHLD is sent when the backgrounded process finishes. SIGPIPE is sent when you write to a filehandle whose child process has closed (an untrapped SIGPIPE can cause your program to silently die). This is not an issue with system("cmd&").

Zombies

You have to be prepared to "reap" the child process when it finishes.

$SIG{CHLD} = sub { wait };

$SIG{CHLD} = 'IGNORE';

You can also use a double fork. You immediately wait() for your first child, and the init daemon will wait() for your grandchild once it exits.

unless ($pid = fork) {
    unless (fork) {
        exec "what you really wanna do";
        die "exec failed!";
    }
    exit 0;
}
waitpid($pid, 0);

See Signals in perlipc for other examples of code to do this. Zombies are not an issue with system("prog &").

Answer 2

Have you tried?

system('xterm -geometry 80x25-5-5 -bg green &');

http://www.rocketaware.com/perl/perlfaq8/How_do_I_start_a_process_in_the_.htm

Answer 3

Perl's system function has two modes:

1. taking a single string and passing it to the command shell to allow special characters to be processed
2. taking a list of strings, exec'ing the first and passing the remaining strings as arguments

In the first form you have to be careful to escape characters that might have a special meaning to the shell. The second form is generally safer since arguments are passed directly to the program being exec'd without the shell being involved.

In your case you seem to be mixing the two forms. The & character only has the meaning of "start this program in the background" if it is passed to the shell. In your program, the ampersand is being passed as the 5th argument to the xterm command.

As Jakob Kruse said the simple answer is to use the single string form of system. If any of the arguments came from an untrusted source you'd have to use quoting or escaping to make them safe.

If you prefer to use the multi-argument form then you'll need to call fork() and then probably use exec() rather than system().

Answer 4

This is not purely an explanation for Perl. The same problem is under C and other languages.

First understand what the system command does:

1. Forks
2. Under the child process call exec
3. The parent process is waiting for forked child process to finish

It does not matter if you pass multiple arguments or one argument. The difference is, with multiple arguments, the command is executed directly. With one argument, the command is wrapped by the shell, and finally executed as:

/bin/sh -c your_command_with_redirections_and_ambersand

When you pass a command as some_command par1 par2 &, then between the Perl interpreter and the command is the sh or bash process used as a wrapper, and it is waiting for some_command finishing. Your script is waiting for the shell interpreter, and no additional waitpid is needed, because Perl's function system does it for you.

When you want to implement this mechanism directly in your script, you should:

1. Use the fork function. See example: http://users.telenet.be/bartl/classicperl/fork/all.html
2. Under the child condition (if), use the exec function. Your user is similar to system, see the manual. Notice, exec causes the child process program/content/data cover by the executed command.
3. Under the parent condition (if, fork exits with non-zero), you use waitpid, using pid returned by the fork function.

This is why you can run the process in the background. I hope this is simple.

The simplest example:

if (my $pid = fork) { #exits 0 = false for child process, at this point is brain split
  # parent ($pid is process id of child)
  # Do something what you want, asynchronously with executed command
  waitpid($pid);  # Wait until child ends
  # If you don't want to, don't wait. Your process ends, and then the child process will be relinked
  # from your script to INIT process, and finally INIT will assume the child finishing.
  # Alternatively, you can handle the SIGCHLD signal in your script
}
else {
  # Child
  exec('some_command arg1 arg2'); #or exec('some_command','arg1','arg2');
  #exit is not needed, because exec completely overwrites the process content
}