It is often easier to use a program written by someone else than to invent one's own. This section describes how to execute a program from within another. The ``System'' Function

The easiest way to execute a program from another is to use the standard library routine system . system takes one argument, a command string exactly as typed at the terminal (except for the newline at the end) and executes it. For instance, to time-stamp the output of a program,

1 main() { system("date"); /* rest of processing */ }

2 If the command string has to be built from pieces, the in-memory formatting capabilities of sprintf may be useful.

Remember than getc and putc normally buffer their input; terminal I/O will not be properly synchronized unless this buffering is defeated. For output, use fflush ; for input, see setbuf in the appendix. Low-Level Process Creation \(em Execl and Execv

If you're not using the standard library, or if you need finer control over what happens, you will have to construct calls to other programs using the more primitive routines that the standard library's system routine is based on.

The most basic operation is to execute another program .ul without T returning , by using the routine execl . To print the date as the last action of a running program, use

1 execl("/bin/date", "date", NULL);

2 The first argument to execl is the .ul file name of the command; you have to know where it is found in the file system. The second argument is conventionally the program name (that is, the last component of the file name), but this is seldom used except as a place-holder. If the command takes arguments, they are strung out after this; the end of the list is marked by a NULL argument.

The execl call overlays the existing program with the new one, runs that, then exits. There is .ul no return to the original program.

More realistically, a program might fall into two or more phases that communicate only through temporary files. Here it is natural to make the second pass simply an execl call from the first.

The one exception to the rule that the original program never gets control back occurs when there is an error, for example if the file can't be found or is not executable. If you don't know where date is located, say

1 execl("/bin/date", "date", NULL); execl("/usr/bin/date", "date", NULL); fprintf(stderr, "Someone stole 'date'\en");

2

A variant of execl called execv is useful when you don't know in advance how many arguments there are going to be. The call is

1 execv(filename, argp);

2 where argp is an array of pointers to the arguments; the last pointer in the array must be NULL so execv can tell where the list ends. As with execl , filename is the file in which the program is found, and argp[0] is the name of the program. (This arrangement is identical to the argv array for program arguments.)

Neither of these routines provides the niceties of normal command execution. There is no automatic search of multiple directories \(em you have to know precisely where the command is located. Nor do you get the expansion of metacharacters like < , > , * , ? , and [] in the argument list. If you want these, use execl to invoke the shell sh , which then does all the work. Construct a string commandline that contains the complete command as it would have been typed at the terminal, then say

1 execl("/bin/sh", "sh", "-c", commandline, NULL);

2 The shell is assumed to be at a fixed place, /bin/sh . Its argument -c says to treat the next argument as a whole command line, so it does just what you want. The only problem is in constructing the right information in commandline . Control of Processes \(em Fork and Wait

So far what we've talked about isn't really all that useful by itself. Now we will show how to regain control after running a program with execl or execv . Since these routines simply overlay the new program on the old one, to save the old one requires that it first be split into two copies; one of these can be overlaid, while the other waits for the new, overlaying program to finish. The splitting is done by a routine called fork :

1 proc_id = fork();

2 splits the program into two copies, both of which continue to run. The only difference between the two is the value of proc_id , the ``process id.'' In one of these processes (the ``child''), proc_id is zero. In the other (the ``parent''), proc_id is non-zero; it is the process number of the child. Thus the basic way to call, and return from, another program is

1 if (fork() == 0) execl("/bin/sh", "sh", "-c", cmd, NULL); /* in child */

2 And in fact, except for handling errors, this is sufficient. The fork makes two copies of the program. In the child, the value returned by fork is zero, so it calls execl which does the command and then dies. In the parent, fork returns non-zero so it skips the execl. (If there is any error, fork returns -1 ).

More often, the parent wants to wait for the child to terminate before continuing itself. This can be done with the function wait :

1 int status; if (fork() == 0) execl(...); wait(&status);

2 This still doesn't handle any abnormal conditions, such as a failure of the execl or fork , or the possibility that there might be more than one child running simultaneously. (The wait returns the process id of the terminated child, if you want to check it against the value returned by fork .) Finally, this fragment doesn't deal with any funny behavior on the part of the child (which is reported in status ). Still, these three lines are the heart of the standard library's system routine, which we'll show in a moment.

The status returned by wait encodes in its low-order eight bits the system's idea of the child's termination status; it is 0 for normal termination and non-zero to indicate various kinds of problems. The next higher eight bits are taken from the argument of the call to exit which caused a normal termination of the child process. It is good coding practice for all programs to return meaningful status.

When a program is called by the shell, the three file descriptors 0, 1, and 2 are set up pointing at the right files, and all other possible file descriptors are available for use. When this program calls another one, correct etiquette suggests making sure the same conditions hold. Neither fork nor the exec calls affects open files in any way. If the parent is buffering output that must come out before output from the child, the parent must flush its buffers before the execl . Conversely, if a caller buffers an input stream, the called program will lose any information that has been read by the caller. Pipes

A .ul pipe is an I/O channel intended for use between two cooperating processes: one process writes into the pipe, while the other reads. The system looks after buffering the data and synchronizing the two processes. Most pipes are created by the shell, as in

1 ls | pr

2 which connects the standard output of ls to the standard input of pr . Sometimes, however, it is most convenient for a process to set up its own plumbing; in this section, we will illustrate how the pipe connection is established and used.

The system call pipe creates a pipe. Since a pipe is used for both reading and writing, two file descriptors are returned; the actual usage is like this:

1 int fd[2]; stat = pipe(fd); if (stat == -1) /* there was an error ... */

2 fd is an array of two file descriptors, where fd[0] is the read side of the pipe and fd[1] is for writing. These may be used in read , write and close calls just like any other file descriptors.

If a process reads a pipe which is empty, it will wait until data arrives; if a process writes into a pipe which is too full, it will wait until the pipe empties somewhat. If the write side of the pipe is closed, a subsequent read will encounter end of file.

To illustrate the use of pipes in a realistic setting, let us write a function called popen(cmd, mode) , which creates a process cmd (just as system does), and returns a file descriptor that will either read or write that process, according to mode . That is, the call

1 fout = popen("pr", WRITE);

2 creates a process that executes the pr command; subsequent write calls using the file descriptor fout will send their data to that process through the pipe.

popen first creates the the pipe with a pipe system call; it then fork s to create two copies of itself. The child decides whether it is supposed to read or write, closes the other side of the pipe, then calls the shell (via execl ) to run the desired process. The parent likewise closes the end of the pipe it does not use. These closes are necessary to make end-of-file tests work properly. For example, if a child that intends to read fails to close the write end of the pipe, it will never see the end of the pipe file, just because there is one writer potentially active.

1 #include <stdio.h> #define READ 0 #define WRITE 1 #define tst(a, b) (mode == READ ? (b) : (a)) static int popen_pid; popen(cmd, mode) char *cmd; int mode; { int p[2]; if (pipe(p) < 0) return(NULL); if ((popen_pid = fork()) == 0) { close(tst(p[WRITE], p[READ])); close(tst(0, 1)); dup(tst(p[READ], p[WRITE])); close(tst(p[READ], p[WRITE])); execl("/bin/sh", "sh", "-c", cmd, 0); _exit(1); /* disaster has occurred if we get here */ } if (popen_pid == -1) return(NULL); close(tst(p[READ], p[WRITE])); return(tst(p[WRITE], p[READ])); }

2 The sequence of close s in the child is a bit tricky. Suppose that the task is to create a child process that will read data from the parent. Then the first close closes the write side of the pipe, leaving the read side open. The lines

1 close(tst(0, 1)); dup(tst(p[READ], p[WRITE]));

2 are the conventional way to associate the pipe descriptor with the standard input of the child. The close closes file descriptor 0, that is, the standard input. dup is a system call that returns a duplicate of an already open file descriptor. File descriptors are assigned in increasing order and the first available one is returned, so the effect of the dup is to copy the file descriptor for the pipe (read side) to file descriptor 0; thus the read side of the pipe becomes the standard input. (Yes, this is a bit tricky, but it's a standard idiom.) Finally, the old read side of the pipe is closed.

A similar sequence of operations takes place when the child process is supposed to write from the parent instead of reading. You may find it a useful exercise to step through that case.

The job is not quite done, for we still need a function pclose to close the pipe created by popen . The main reason for using a separate function rather than close is that it is desirable to wait for the termination of the child process. First, the return value from pclose indicates whether the process succeeded. Equally important when a process creates several children is that only a bounded number of unwaited-for children can exist, even if some of them have terminated; performing the wait lays the child to rest. Thus:

1 #include <signal.h> pclose(fd) /* close pipe fd */ int fd; { register r, (*hstat)(), (*istat)(), (*qstat)(); int status; extern int popen_pid; close(fd); istat = signal(SIGINT, SIG_IGN); qstat = signal(SIGQUIT, SIG_IGN); hstat = signal(SIGHUP, SIG_IGN); while ((r = wait(&status)) != popen_pid && r != -1); if (r == -1) status = -1; signal(SIGINT, istat); signal(SIGQUIT, qstat); signal(SIGHUP, hstat); return(status); }

2 The calls to signal make sure that no interrupts, etc., interfere with the waiting process; this is the topic of the next section.

The routine as written has the limitation that only one pipe may be open at once, because of the single shared variable popen_pid ; it really should be an array indexed by file descriptor. A popen function, with slightly different arguments and return value is available as part of the standard I/O library discussed below. As currently written, it shares the same limitation.