.NHPROCESSES.PPIt is often easier to use a program writtenby someone else than to invent one's own.This section describes how toexecute a program from within another..NH 2The ``System'' Function.PPThe easiest way to execute a program from anotheris to usethe standard library routine.UL system ..UL systemtakes one argument, a command string exactly as typedat the terminal(except for the newline at the end)and executes it.For instance, to time-stamp the output of a program,.P1main(){	system("date");	/* rest of processing */}.P2If the command string has to be built from pieces,the in-memory formatting capabilities of.UL sprintfmay be useful..PPRemember than.UL getcand.UL putcnormally buffer their input;terminal I/O will not be properly synchronized unlessthis buffering is defeated.For output, use .UL fflush ;for input, see.UL setbuf in the appendix..NH 2Low-Level Process Creation \(em Execl and Execv.PPIf you're not using the standard library,or if you need finer control over whathappens,you will have to construct calls to other programsusing the more primitive routines that the standardlibrary's.UL systemroutine is based on..PPThe most basic operation is to execute another program.ulwithout.IT returning ,by using the routine.UL execl  .To print the date as the last action of a running program,use.P1execl("/bin/date", "date", NULL);.P2The first argument to.UL execlis the.ulfile nameof the command; you have to know where it is foundin the file system.The second argument is conventionallythe 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 afterthis;the end of the list is marked by a .UL NULLargument..PPThe.UL execlcalloverlays the existing program withthe new one,runs that, then exits.There is.ulnoreturn to the original program..PPMore realistically,a program might fall into two or more phasesthat communicate only through temporary files.Here it is natural to make the second passsimply an.UL execlcall from the first..PPThe one exception to the rule that the original program never gets controlback occurs when there is an error, for example if the file can't be foundor is not executable.If you don't know where.UL dateis located, say.P1execl("/bin/date", "date", NULL);execl("/usr/bin/date", "date", NULL);fprintf(stderr, "Someone stole 'date'\n");.P2.PPA variant of.UL execlcalled.UL execvis useful when you don't know in advance how many arguments there are going to be.The call is.P1execv(filename, argp);.P2where.UL argpis an array of pointers to the arguments;the last pointer in the array must be .UL NULLso.UL execvcan tell where the list ends.As with.UL execl ,.UL filenameis the file in which the program is found, and.UL argp[0]is the name of the program.(This arrangement is identical to the.UL argvarray for program arguments.).PPNeither of these routines provides the niceties of normal command execution.There is no automatic search of multiple directories \(emyou have to know precisely where the command is located.Nor do you get the expansion of metacharacters like.UL < ,.UL > ,.UL * ,.UL ? ,and.UL []in the argument list.If you want these, use.UL execlto invoke the shell.UL sh ,which then does all the work.Construct a string.UL commandlinethat contains the complete command as it would have been typedat the terminal, then say.P1execl("/bin/sh", "sh", "-c", commandline, NULL);.P2The shell is assumed to be at a fixed place,.UL /bin/sh .Its argument.UL -csays to treat the next argumentas a whole command line, so it does just what you want.The only problem is in constructing the right informationin.UL commandline ..NH 2Control of Processes \(em Fork and Wait.PPSo far what we've talked about isn't really all that useful by itself.Now we will show how to regain control after runninga program with.UL execlor.UL execv .Since these routines simply overlay the new program on the old one,to save the old one requires that it first be split intotwo 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.UL fork :.P1proc_id = fork();.P2splits the program into two copies, both of which continue to run.The only difference between the two is the value of.UL proc_id ,the ``process id.''In one of these processes (the ``child''),.UL proc_idis zero.In the other(the ``parent''),.UL proc_idis non-zero; it is the process number of the child.Thus the basic way to call, and return from,another program is.P1if (fork() == 0)	execl("/bin/sh", "sh", "-c", cmd, NULL);	/* in child */.P2And in fact, except for handling errors, this is sufficient.The.UL forkmakes two copies of the program.In the child, the value returned by.UL forkis zero, so it calls.UL execlwhich does the.UL commandand then dies.In the parent,.UL forkreturns non-zeroso it skips the.UL execl.(If there is any error,.UL forkreturns.UL -1 )..PPMore often, the parent wants to wait for the child to terminatebefore continuing itself.This can be done withthe function.UL wait :.P1int status;if (fork() == 0)	execl(...);wait(&status);.P2This still doesn't handle any abnormal conditions, such as a failureof the.UL execlor.UL fork ,or the possibility that there might be more than one child running simultaneously.(The.UL waitreturns theprocess idof the terminated child, if you want to check it against the valuereturned by.UL fork .)Finally, this fragment doesn't deal with anyfunny behavior on the part of the child(which is reported in.UL status ).Still, these three linesare the heart of the standard library's.UL systemroutine,which we'll show in a moment..PPThe.UL  status returned by.UL waitencodes in its low-order eight bitsthe system's idea of the child's termination status;it is 0 for normal termination and non-zero to indicatevarious kinds of problems.The next higher eight bits are taken from the argumentof the call to.UL exitwhich caused a normal termination of the child process.It is good coding practicefor all programs to return meaningfulstatus..PPWhen a program is called by the shell,the three file descriptors0, 1, and 2 are set up pointing at the right files,and all other possible file descriptorsare available for use.When this program calls another one,correct etiquette suggests making sure the same conditionshold.Neither.UL forknor the.UL execcalls affects open files in any way.If the parent is buffering outputthat must come out before output from the child,the parent must flush its buffersbefore the.UL execl .Conversely,if a caller buffers an input stream,the called program will lose any informationthat has been read by the caller..NH 2Pipes.PPA.ulpipeis an I/O channel intended for usebetween two cooperating processes:one process writes into the pipe,while the other reads.The system looks after buffering the data and synchronizingthe two processes.Most pipes are created by the shell,as in.P1ls | pr.P2which connects the standard output of.UL lsto the standard input of.UL pr .Sometimes, however, it is most convenientfor a process to set up its own plumbing;in this section, we will illustrate howthe pipe connection is established and used..PPThe system call.UL pipecreates a pipe.Since a pipe is used for both reading and writing,two file descriptors are returned;the actual usage is like this:.P1int	fd[2];stat = pipe(fd);if (stat == -1)	/* there was an error ... */.P2.UL fdis an array of two file descriptors, where.UL fd[0]is the read side of the pipe and.UL fd[1] is for writing.These may be used in.UL read ,.UL writeand.UL closecalls just like any other file descriptors..PPIf a process reads a pipe which is empty,it will wait until data arrives;if a process writes into a pipe whichis too full, it will wait until the pipe empties somewhat.If the write side of the pipe is closed,a subsequent.UL  read will encounter end of file..PPTo illustrate the use of pipes in a realistic setting,let us write a function called.UL popen(cmd,\ mode) ,which creates a process.UL cmd(just as.UL system does),and returns a file descriptor that will eitherread or write that process, according to .UL mode .That is,the call.P1fout = popen("pr", WRITE);.P2creates a process that executesthe.UL prcommand;subsequent.UL writecalls using the file descriptor.UL foutwill send their data to that processthrough the pipe..PP.UL popenfirst creates thethe pipe with a.UL pipesystem call;it then.UL fork sto 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.UL 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 readfails to close the write end of the pipe, it will neversee the end of the pipe file, just because there is one writerpotentially active..P1#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]));}.P2The sequence of.UL close sin the childis a bit tricky.Supposethat the task is to create a child process that will read data from the parent.Then the first.UL closecloses the write side of the pipe,leaving the read side open.The lines.P1close(tst(0, 1));dup(tst(p[READ], p[WRITE]));.P2are the conventional way to associate the pipe descriptorwith the standard input of the child.The .UL closecloses file descriptor 0,that is, the standard input..UL dupis a system call thatreturns a duplicate of an already open file descriptor.File descriptors are assigned in increasing orderand the first available one is returned,sothe effect of the.UL dupis 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..PPA similar sequence of operations takes placewhen the child process is supposed to writefrom the parent instead of reading.You may find it a useful exercise to step through that case..PPThe job is not quite done,for we still need a function.UL pcloseto close the pipe created by.UL popen .The main reason for using a separate function rather than.UL closeis that it is desirable to wait for the termination of the child process.First, the return value from.UL pcloseindicates whether the process succeeded.Equally important when a process creates several childrenis that only a bounded number of unwaited-for childrencan exist, even if some of them have terminated;performing the.UL waitlays the child to rest.Thus:.P1#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);}.P2The calls to.UL signalmake sure that no interrupts, etc.,interfere with the waiting process;this is the topic of the next section..PPThe routine as written has the limitation that only one pipe maybe open at once, because of the single shared variable.UL popen_pid ;it really should be an array indexed by file descriptor.A.UL popenfunction, with slightly different arguments and return value is availableas part of the standard I/O library discussed below.As currently written, it shares the same limitation.