The scalar context use of backquotes returns the captured as a single long string, even if it looks to you like there are multiple “lines” because it has newlines. However, using the same backquoted string in a list context yields a list containing one line of output per element.

For example, the Unix who command normally spits out a line of text for each current login on the system as follows:

merlyn tty/42 Dec 7 19:41 
rootbeer console Dec 2 14:15 
rootbeer tty/12 Dec 6 23:00

The left column is the username, the middle column is the TTY name (that is, the name of the user’s connection to the machine), and the rest of the line is the date and time of login (and possibly remote login information, but not in this example). In a scalar context, you get all that at once, which you would then need to split up on your own:

my $who_text = `who`;
my @who_lines = split /\n/, $who_text;

But in a list context, we automatically get the data broken up by lines:

my @who_lines = `who`;

You’ll have a number of separate elements in @who_lines, each one terminated by a newline. Of course, adding a chomp around the outside of that will rip off those newlines, but you can go a different direction. If you put that as part of the value for a foreach, you’ll iterate over the lines automatically, placing each one in $_:

foreach (`who`) {
    my($user, $tty, $date) = /(\S+)\s+(\S+)\s+(.*)/; 
    $ttys{$user} .= "$tty at $date\n";
}

External Process with IPC::System::Simple

Running or capturing output from external commands is tricky business, especially since Perl aims to work on so many diverse platforms, each with their own way of doing things. Paul Fenwick’s IPC::System::Simple module fixes that by providing a simpler interface that hides the complexity of the operating system-specific stuff. It doesn’t come with Perl (yet), so you have to get it from CPAN.

There’s really not that much to say about this module because it is truly simple. You can use it to replace the built-in system with its own more robust version:

use IPC::System::Simple qw(system);
my $tarfile = 'something*wicked.tar';
my @dirs = qw(fred|flintstone <barney&rubble> betty ); 
system 'tar', 'cvf', $tarfile, @dirs;

It also provides a systemx that never uses the shell, so you should never have the problem of unintended shell actions:

systemx 'tar', 'cvf', $tarfile, @dirs;

If you want to capture the output, you change the system or systemx to capture or capturex, both of which work like backquotes (but better):

my @output = capturex 'tar', 'cvf', $tarfile, @dirs;

Processes as File handles

So far, you’ve seen ways to deal with synchronous processes, where Perl stays in charge, launches a command, (usually) waits for it to finish, then possibly grabs its output. But Perl can also launch a child process that stays alive, communicating to Perl on an ongoing basis until the task is complete.

The syntax for launching a concurrent (parallel) child process is to put the command as the “filename” for an open call, and either precede or follow the command with a vertical bar, which is the “pipe” character. For that reason, this is often called a piped open. In the two-argument form, the pipe goes before or after the command that you want to run:

open DATE, 'date|' or die "cannot pipe from date: $!";
open MAIL, '|mail merlyn' or die "cannot pipe to mail: $!";

In the first example, with the vertical bar on the right, Perl launches the command with its standard output connected to the DATE file handle opened for reading, similar to the way that the command date | your_program would work from the shell. In the second example, with the vertical bar on the left, Perl connects the command’s standard input to the MAIL file handle opened for writing, similar to what happens with the command your_program | mail merlyn. In either case, the command continues independently of the Perl process. (If the Perl process exits before the command is complete, a command that’s been reading will see end-of-file, while a command that’s been writing will get a “broken pipe” error signal on the next write, by default.) The open fails if Perl can’t start the child process. If the command itself does not exist or exits erroneously, Perl will not see this as an error when opening the file handle, but as an error when closing it. We’ll get to that in a moment.

The three-argument form is a bit tricky because for the read file handle, the pipe character comes after the command. There are special modes for that though. For the file handle mode, if you want a read file handle, you use -|, and if you want a write file handle, you use |- to show which side of the pipe you want to place the command:

open my $date_fh, '-|', 'date' or die "cannot pipe from date: $!"; 
open my $mail_fh, '|-', 'mail merlyn'
    or die "cannot pipe to mail: $!";

The pipe opens can also take more than three commands. The fourth and subsequent arguments become the arguments to the command, so you can break up that command string to separate the command name from its arguments:

open my $mail_fh, '|-', 'mail', 'merlyn' 
    or die "cannot pipe to mail: $!";

Either way, for all intents and purposes, the rest of the program doesn’t know, doesn’t care, and would have to work pretty hard to figure out that this is a file handle opened on a process rather than on a file. So, to get data from a file handle opened for reading, you read the file handle normally:

$now = <$date_fh>;

And to send data to the mail process (waiting for the body of a message to deliver to merlyn on standard input), a simple print-with-a-file handle will do:

print $mail_fh "The time is now $now"; # presume $now ends in newline

If a process is connected to a file handle that is open for reading, and then exits, the file handle returns end-of-file, just like reading up to the end of a normal file. When you close a file handle open for writing to a process, the process will see end-of-file. So, to finish sending the email, close the handle:

close $mail_fh;
die "mail: non-zero exit of $?" if $?;

Closing a file handle attached to a process waits for the process to complete so that Perl can get the process’s exit status. The exit status is then available in the $? variable (reminiscent of the same variable in the Bourne Shell) and is the same kind of number as the value returned by the system function: zero for success, nonzero for failure. Each new exited process overwrites the previous value though, so save it quickly if you want it.

The processes are synchronized just like a pipelined command. If you try to read and no data is available, the process is suspended (without consuming additional CPU time) until the sending program has started speaking again. Similarly, if a writing process gets ahead of the reading process, the writing process is slowed down until the reader starts to catch up. There’s a buffer (usually 8 KB or so) in between, so they don’t have to stay precisely in lockstep.

Why use processes as file handles? Well, it’s the only easy way to write to a process based on the results of a computation. But if you’re just reading, backquotes are often much easier to manage, unless you want to have the results as they come in.

For example, the Unix find command locates files based on their attributes, and it can take quite a while if used on a fairly large number of files (such as starting from the root directory). You can put a find command inside backquotes, but it’s often nicer to see the results as they are found:

open my $find_fh, '-|',
    'find', qw( / -atime +90 -size +1000 -print )
        or die "fork: $!";
        
while (<$find_fh>) { 
    chomp;
    printf "%s size %dK last accessed %.2f days ago\n", $_, (1023 + -s $_)/1024, -A $_;
}

That find command looks for all the files that have not been accessed within the past 90 days and that are larger than 1,000 blocks (these are good candidates to move to longer-term storage). While find is searching and searching, Perl can wait. As it finds each file, Perl responds to the incoming name and displays some information about that file for further research. Had this been written with backquotes, you would not see any output until the find command had finished, and it’s comforting to see that it’s actually doing the job even before it’s done.

Getting Down and Dirty with Fork

In addition to the high-level interfaces already described, Perl provides nearly direct access to the low-level process management system calls of Unix and some other systems. Let's take a look at a quick reimplementation of this:

system 'date';

You can do that using the low-level system calls:

defined(my $pid = fork) or die "Cannot fork: $!"; 
unless ($pid) {
    # Child process is here exec 'date';
    die "cannot exec date: $!";
}
# Parent process is here 
waitpid($pid, 0);

Here, you check the return value from fork, which is undef if it failed. Usually it succeeds, causing two separate processes to continue to the next line, but only the parent process has a nonzero value in $pid, so only the child process executes the exec function. The parent process skips over that and executes the waitpid function, waiting for that particular child to finish.

Sending and Receiving Signals

A Unix signal is a tiny message sent to a process. Different signals are identified by a name (such as SIGINT, meaning “interrupt signal”) and a corresponding small integer (in the range from 1 to 16, 1 to 32, or 1 to 63, depending on your Unix flavor). Programs or the operating system typically send signals to another program when a significant event happens, such as pressing the interrupt character (typically Control-C) on the terminal, which sends a SIGINT to all the processes attached to that terminal. Some signals are sent automatically by the system, but they can also come from another process.

You can send signals from your Perl process to another process, but you have to know the target’s process ID number. How you figure that out is a bit complicated, but let’s say you know that you want to send a SIGINT to process 4201. That’s easy enough if you know that SIGINT corresponds to the number 2(On a Unix system, you can get a list by running kill -l on the command line):

kill 2, 4201 or die "Cannot signal 4201 with SIGINT: $!";

It’s named “kill” because one of the primary purposes of signals is to stop a process that’s gone on long enough. You can also use the string 'INT' in place of the 2, so you don’t have to know the number:

kill 'INT', 4201 or die "Cannot signal 4201 with SIGINT: $!";

You can even use the => operator to automatically quote the signal name:

kill INT => 4201 or die "Cannot signal 4201 with SIGINT: $!";

If the process no longer exists, you’ll get a false return value, so you can also use this technique to see whether a process is still alive. A special signal number of 0 says “just check to see whether I could send a signal if I wanted to, but I don’t want to, so don’t actually send anything.” So a process probe might look like:

unless (kill 0, $pid) {
    warn "$pid has gone away!"; 
}

Perhaps a little more interesting than sending signals is catching signals. Why might you want to do this? Well, suppose you have a program that creates files in /tmp, and you normally delete those files at the end of the program. If someone presses Control-C during the execution, that leaves trash in /tmp, a very impolite thing to do. To fix this, you can create a signal handler that takes care of the cleanup:

my $temp_directory = "/tmp/myprog.$$"; # create files below here
mkdir $temp_directory, 0700 or die "Cannot create $temp_directory: $!";

sub clean_up {
    unlink glob "$temp_directory/*";
    rmdir $temp_directory; 
}

sub my_int_handler { 
    &clean_up();
    die "interrupted, exiting...\n"; 
}

$SIG{'INT'} = 'my_int_handler';

# Time passes, the program runs, creates some temporary
# files in the temp directory, maybe someone presses Control-C .
# Now it's the end of normal execution
&clean_up();

If the subroutine returns rather than exiting, execution resumes right where the signal interrupted it. This can be useful if the signal needs to actually interrupt something rather than causing it to stop. For example, suppose processing each line of a file takes a few seconds, which is pretty slow, and you want to abort the overall processing when an interrupt is processed—but not in the middle of processing a line. Just set a flag in the signal procedure and check it at the end of each line’s processing:

my $int_count = 0;
sub my_int_handler { 
    $int_count++ 
} 
$SIG{'INT'} = 'my_int_handler'; 
#...;
while (<SOMEFILE>) {
    #...; # some processing that takes a few seconds ... 
    if ($int_count) {
        # interrupt was seen!
        print "[processing interrupted...]\n"; 
        last;
    } 
}

So, you can either set a flag or break out of the program, and that covers most of what you’ll need from catching signals. For the most part, Perl will only handle a signal once it reaches a safe point to do so. For instance, Perl will not deliver most signals in the middle of allocating memory or rearranging its internal data structures. Perl delivers some signals, such as SIGILL, SIGBUS, and SIGSEGV, right away, so those are still unsafe.