Commit | Line | Data |
---|---|---|
035eb8bc C |
1 | .NH |
2 | PROCESSES | |
3 | .PP | |
4 | It is often easier to use a program written | |
5 | by someone else than to invent one's own. | |
6 | This section describes how to | |
7 | execute a program from within another. | |
8 | .NH 2 | |
9 | The ``System'' Function | |
10 | .PP | |
11 | The easiest way to execute a program from another | |
12 | is to use | |
13 | the standard library routine | |
14 | .UL system . | |
15 | .UL system | |
16 | takes one argument, a command string exactly as typed | |
17 | at the terminal | |
18 | (except for the newline at the end) | |
19 | and executes it. | |
20 | For instance, to time-stamp the output of a program, | |
21 | .P1 | |
22 | main() | |
23 | { | |
24 | system("date"); | |
25 | /* rest of processing */ | |
26 | } | |
27 | .P2 | |
28 | If the command string has to be built from pieces, | |
29 | the in-memory formatting capabilities of | |
30 | .UL sprintf | |
31 | may be useful. | |
32 | .PP | |
33 | Remember than | |
34 | .UL getc | |
35 | and | |
36 | .UL putc | |
37 | normally buffer their input; | |
38 | terminal I/O will not be properly synchronized unless | |
39 | this buffering is defeated. | |
40 | For output, use | |
41 | .UL fflush ; | |
42 | for input, see | |
43 | .UL setbuf | |
44 | in the appendix. | |
45 | .NH 2 | |
46 | Low-Level Process Creation \(em Execl and Execv | |
47 | .PP | |
48 | If you're not using the standard library, | |
49 | or if you need finer control over what | |
50 | happens, | |
51 | you will have to construct calls to other programs | |
52 | using the more primitive routines that the standard | |
53 | library's | |
54 | .UL system | |
55 | routine is based on. | |
56 | .PP | |
57 | The most basic operation is to execute another program | |
58 | .ul | |
59 | without | |
60 | .IT returning , | |
61 | by using the routine | |
62 | .UL execl . | |
63 | To print the date as the last action of a running program, | |
64 | use | |
65 | .P1 | |
66 | execl("/bin/date", "date", NULL); | |
67 | .P2 | |
68 | The first argument to | |
69 | .UL execl | |
70 | is the | |
71 | .ul | |
72 | file name | |
73 | of the command; you have to know where it is found | |
74 | in the file system. | |
75 | The second argument is conventionally | |
76 | the program name | |
77 | (that is, the last component of the file name), | |
78 | but this is seldom used except as a place-holder. | |
79 | If the command takes arguments, they are strung out after | |
80 | this; | |
81 | the end of the list is marked by a | |
82 | .UL NULL | |
83 | argument. | |
84 | .PP | |
85 | The | |
86 | .UL execl | |
87 | call | |
88 | overlays the existing program with | |
89 | the new one, | |
90 | runs that, then exits. | |
91 | There is | |
92 | .ul | |
93 | no | |
94 | return to the original program. | |
95 | .PP | |
96 | More realistically, | |
97 | a program might fall into two or more phases | |
98 | that communicate only through temporary files. | |
99 | Here it is natural to make the second pass | |
100 | simply an | |
101 | .UL execl | |
102 | call from the first. | |
103 | .PP | |
104 | The one exception to the rule that the original program never gets control | |
105 | back occurs when there is an error, for example if the file can't be found | |
106 | or is not executable. | |
107 | If you don't know where | |
108 | .UL date | |
109 | is located, say | |
110 | .P1 | |
111 | execl("/bin/date", "date", NULL); | |
112 | execl("/usr/bin/date", "date", NULL); | |
113 | fprintf(stderr, "Someone stole 'date'\n"); | |
114 | .P2 | |
115 | .PP | |
116 | A variant of | |
117 | .UL execl | |
118 | called | |
119 | .UL execv | |
120 | is useful when you don't know in advance how many arguments there are going to be. | |
121 | The call is | |
122 | .P1 | |
123 | execv(filename, argp); | |
124 | .P2 | |
125 | where | |
126 | .UL argp | |
127 | is an array of pointers to the arguments; | |
128 | the last pointer in the array must be | |
129 | .UL NULL | |
130 | so | |
131 | .UL execv | |
132 | can tell where the list ends. | |
133 | As with | |
134 | .UL execl , | |
135 | .UL filename | |
136 | is the file in which the program is found, and | |
137 | .UL argp[0] | |
138 | is the name of the program. | |
139 | (This arrangement is identical to the | |
140 | .UL argv | |
141 | array for program arguments.) | |
142 | .PP | |
143 | Neither of these routines provides the niceties of normal command execution. | |
144 | There is no automatic search of multiple directories \(em | |
145 | you have to know precisely where the command is located. | |
146 | Nor do you get the expansion of metacharacters like | |
147 | .UL < , | |
148 | .UL > , | |
149 | .UL * , | |
150 | .UL ? , | |
151 | and | |
152 | .UL [] | |
153 | in the argument list. | |
154 | If you want these, use | |
155 | .UL execl | |
156 | to invoke the shell | |
157 | .UL sh , | |
158 | which then does all the work. | |
159 | Construct a string | |
160 | .UL commandline | |
161 | that contains the complete command as it would have been typed | |
162 | at the terminal, then say | |
163 | .P1 | |
164 | execl("/bin/sh", "sh", "-c", commandline, NULL); | |
165 | .P2 | |
166 | The shell is assumed to be at a fixed place, | |
167 | .UL /bin/sh . | |
168 | Its argument | |
169 | .UL -c | |
170 | says to treat the next argument | |
171 | as a whole command line, so it does just what you want. | |
172 | The only problem is in constructing the right information | |
173 | in | |
174 | .UL commandline . | |
175 | .NH 2 | |
176 | Control of Processes \(em Fork and Wait | |
177 | .PP | |
178 | So far what we've talked about isn't really all that useful by itself. | |
179 | Now we will show how to regain control after running | |
180 | a program with | |
181 | .UL execl | |
182 | or | |
183 | .UL execv . | |
184 | Since these routines simply overlay the new program on the old one, | |
185 | to save the old one requires that it first be split into | |
186 | two copies; | |
187 | one of these can be overlaid, while the other waits for the new, | |
188 | overlaying program to finish. | |
189 | The splitting is done by a routine called | |
190 | .UL fork : | |
191 | .P1 | |
192 | proc_id = fork(); | |
193 | .P2 | |
194 | splits the program into two copies, both of which continue to run. | |
195 | The only difference between the two is the value of | |
196 | .UL proc_id , | |
197 | the ``process id.'' | |
198 | In one of these processes (the ``child''), | |
199 | .UL proc_id | |
200 | is zero. | |
201 | In the other | |
202 | (the ``parent''), | |
203 | .UL proc_id | |
204 | is non-zero; it is the process number of the child. | |
205 | Thus the basic way to call, and return from, | |
206 | another program is | |
207 | .P1 | |
208 | if (fork() == 0) | |
209 | execl("/bin/sh", "sh", "-c", cmd, NULL); /* in child */ | |
210 | .P2 | |
211 | And in fact, except for handling errors, this is sufficient. | |
212 | The | |
213 | .UL fork | |
214 | makes two copies of the program. | |
215 | In the child, the value returned by | |
216 | .UL fork | |
217 | is zero, so it calls | |
218 | .UL execl | |
219 | which does the | |
220 | .UL command | |
221 | and then dies. | |
222 | In the parent, | |
223 | .UL fork | |
224 | returns non-zero | |
225 | so it skips the | |
226 | .UL execl. | |
227 | (If there is any error, | |
228 | .UL fork | |
229 | returns | |
230 | .UL -1 ). | |
231 | .PP | |
232 | More often, the parent wants to wait for the child to terminate | |
233 | before continuing itself. | |
234 | This can be done with | |
235 | the function | |
236 | .UL wait : | |
237 | .P1 | |
238 | int status; | |
239 | ||
240 | if (fork() == 0) | |
241 | execl(...); | |
242 | wait(&status); | |
243 | .P2 | |
244 | This still doesn't handle any abnormal conditions, such as a failure | |
245 | of the | |
246 | .UL execl | |
247 | or | |
248 | .UL fork , | |
249 | or the possibility that there might be more than one child running simultaneously. | |
250 | (The | |
251 | .UL wait | |
252 | returns the | |
253 | process id | |
254 | of the terminated child, if you want to check it against the value | |
255 | returned by | |
256 | .UL fork .) | |
257 | Finally, this fragment doesn't deal with any | |
258 | funny behavior on the part of the child | |
259 | (which is reported in | |
260 | .UL status ). | |
261 | Still, these three lines | |
262 | are the heart of the standard library's | |
263 | .UL system | |
264 | routine, | |
265 | which we'll show in a moment. | |
266 | .PP | |
267 | The | |
268 | .UL status | |
269 | returned by | |
270 | .UL wait | |
271 | encodes in its low-order eight bits | |
272 | the system's idea of the child's termination status; | |
273 | it is 0 for normal termination and non-zero to indicate | |
274 | various kinds of problems. | |
275 | The next higher eight bits are taken from the argument | |
276 | of the call to | |
277 | .UL exit | |
278 | which caused a normal termination of the child process. | |
279 | It is good coding practice | |
280 | for all programs to return meaningful | |
281 | status. | |
282 | .PP | |
283 | When a program is called by the shell, | |
284 | the three file descriptors | |
285 | 0, 1, and 2 are set up pointing at the right files, | |
286 | and all other possible file descriptors | |
287 | are available for use. | |
288 | When this program calls another one, | |
289 | correct etiquette suggests making sure the same conditions | |
290 | hold. | |
291 | Neither | |
292 | .UL fork | |
293 | nor the | |
294 | .UL exec | |
295 | calls affects open files in any way. | |
296 | If the parent is buffering output | |
297 | that must come out before output from the child, | |
298 | the parent must flush its buffers | |
299 | before the | |
300 | .UL execl . | |
301 | Conversely, | |
302 | if a caller buffers an input stream, | |
303 | the called program will lose any information | |
304 | that has been read by the caller. | |
305 | .NH 2 | |
306 | Pipes | |
307 | .PP | |
308 | A | |
309 | .ul | |
310 | pipe | |
311 | is an I/O channel intended for use | |
312 | between two cooperating processes: | |
313 | one process writes into the pipe, | |
314 | while the other reads. | |
315 | The system looks after buffering the data and synchronizing | |
316 | the two processes. | |
317 | Most pipes are created by the shell, | |
318 | as in | |
319 | .P1 | |
320 | ls | pr | |
321 | .P2 | |
322 | which connects the standard output of | |
323 | .UL ls | |
324 | to the standard input of | |
325 | .UL pr . | |
326 | Sometimes, however, it is most convenient | |
327 | for a process to set up its own plumbing; | |
328 | in this section, we will illustrate how | |
329 | the pipe connection is established and used. | |
330 | .PP | |
331 | The system call | |
332 | .UL pipe | |
333 | creates a pipe. | |
334 | Since a pipe is used for both reading and writing, | |
335 | two file descriptors are returned; | |
336 | the actual usage is like this: | |
337 | .P1 | |
338 | int fd[2]; | |
339 | ||
340 | stat = pipe(fd); | |
341 | if (stat == -1) | |
342 | /* there was an error ... */ | |
343 | .P2 | |
344 | .UL fd | |
345 | is an array of two file descriptors, where | |
346 | .UL fd[0] | |
347 | is the read side of the pipe and | |
348 | .UL fd[1] | |
349 | is for writing. | |
350 | These may be used in | |
351 | .UL read , | |
352 | .UL write | |
353 | and | |
354 | .UL close | |
355 | calls just like any other file descriptors. | |
356 | .PP | |
357 | If a process reads a pipe which is empty, | |
358 | it will wait until data arrives; | |
359 | if a process writes into a pipe which | |
360 | is too full, it will wait until the pipe empties somewhat. | |
361 | If the write side of the pipe is closed, | |
362 | a subsequent | |
363 | .UL read | |
364 | will encounter end of file. | |
365 | .PP | |
366 | To illustrate the use of pipes in a realistic setting, | |
367 | let us write a function called | |
368 | .UL popen(cmd,\ mode) , | |
369 | which creates a process | |
370 | .UL cmd | |
371 | (just as | |
372 | .UL system | |
373 | does), | |
374 | and returns a file descriptor that will either | |
375 | read or write that process, according to | |
376 | .UL mode . | |
377 | That is, | |
378 | the call | |
379 | .P1 | |
380 | fout = popen("pr", WRITE); | |
381 | .P2 | |
382 | creates a process that executes | |
383 | the | |
384 | .UL pr | |
385 | command; | |
386 | subsequent | |
387 | .UL write | |
388 | calls using the file descriptor | |
389 | .UL fout | |
390 | will send their data to that process | |
391 | through the pipe. | |
392 | .PP | |
393 | .UL popen | |
394 | first creates the | |
395 | the pipe with a | |
396 | .UL pipe | |
397 | system call; | |
398 | it then | |
399 | .UL fork s | |
400 | to create two copies of itself. | |
401 | The child decides whether it is supposed to read or write, | |
402 | closes the other side of the pipe, | |
403 | then calls the shell (via | |
404 | .UL execl ) | |
405 | to run the desired process. | |
406 | The parent likewise closes the end of the pipe it does not use. | |
407 | These closes are necessary to make end-of-file tests work properly. | |
408 | For example, if a child that intends to read | |
409 | fails to close the write end of the pipe, it will never | |
410 | see the end of the pipe file, just because there is one writer | |
411 | potentially active. | |
412 | .P1 | |
413 | #include <stdio.h> | |
414 | ||
415 | #define READ 0 | |
416 | #define WRITE 1 | |
417 | #define tst(a, b) (mode == READ ? (b) : (a)) | |
418 | static int popen_pid; | |
419 | ||
420 | popen(cmd, mode) | |
421 | char *cmd; | |
422 | int mode; | |
423 | { | |
424 | int p[2]; | |
425 | ||
426 | if (pipe(p) < 0) | |
427 | return(NULL); | |
428 | if ((popen_pid = fork()) == 0) { | |
429 | close(tst(p[WRITE], p[READ])); | |
430 | close(tst(0, 1)); | |
431 | dup(tst(p[READ], p[WRITE])); | |
432 | close(tst(p[READ], p[WRITE])); | |
433 | execl("/bin/sh", "sh", "-c", cmd, 0); | |
434 | _exit(1); /* disaster has occurred if we get here */ | |
435 | } | |
436 | if (popen_pid == -1) | |
437 | return(NULL); | |
438 | close(tst(p[READ], p[WRITE])); | |
439 | return(tst(p[WRITE], p[READ])); | |
440 | } | |
441 | .P2 | |
442 | The sequence of | |
443 | .UL close s | |
444 | in the child | |
445 | is a bit tricky. | |
446 | Suppose | |
447 | that the task is to create a child process that will read data from the parent. | |
448 | Then the first | |
449 | .UL close | |
450 | closes the write side of the pipe, | |
451 | leaving the read side open. | |
452 | The lines | |
453 | .P1 | |
454 | close(tst(0, 1)); | |
455 | dup(tst(p[READ], p[WRITE])); | |
456 | .P2 | |
457 | are the conventional way to associate the pipe descriptor | |
458 | with the standard input of the child. | |
459 | The | |
460 | .UL close | |
461 | closes file descriptor 0, | |
462 | that is, the standard input. | |
463 | .UL dup | |
464 | is a system call that | |
465 | returns a duplicate of an already open file descriptor. | |
466 | File descriptors are assigned in increasing order | |
467 | and the first available one is returned, | |
468 | so | |
469 | the effect of the | |
470 | .UL dup | |
471 | is to copy the file descriptor for the pipe (read side) | |
472 | to file descriptor 0; | |
473 | thus the read side of the pipe becomes the standard input. | |
474 | (Yes, this is a bit tricky, but it's a standard idiom.) | |
475 | Finally, the old read side of the pipe is closed. | |
476 | .PP | |
477 | A similar sequence of operations takes place | |
478 | when the child process is supposed to write | |
479 | from the parent instead of reading. | |
480 | You may find it a useful exercise to step through that case. | |
481 | .PP | |
482 | The job is not quite done, | |
483 | for we still need a function | |
484 | .UL pclose | |
485 | to close the pipe created by | |
486 | .UL popen . | |
487 | The main reason for using a separate function rather than | |
488 | .UL close | |
489 | is that it is desirable to wait for the termination of the child process. | |
490 | First, the return value from | |
491 | .UL pclose | |
492 | indicates whether the process succeeded. | |
493 | Equally important when a process creates several children | |
494 | is that only a bounded number of unwaited-for children | |
495 | can exist, even if some of them have terminated; | |
496 | performing the | |
497 | .UL wait | |
498 | lays the child to rest. | |
499 | Thus: | |
500 | .P1 | |
501 | #include <signal.h> | |
502 | ||
503 | pclose(fd) /* close pipe fd */ | |
504 | int fd; | |
505 | { | |
506 | register r, (*hstat)(), (*istat)(), (*qstat)(); | |
507 | int status; | |
508 | extern int popen_pid; | |
509 | ||
510 | close(fd); | |
511 | istat = signal(SIGINT, SIG_IGN); | |
512 | qstat = signal(SIGQUIT, SIG_IGN); | |
513 | hstat = signal(SIGHUP, SIG_IGN); | |
514 | while ((r = wait(&status)) != popen_pid && r != -1); | |
515 | if (r == -1) | |
516 | status = -1; | |
517 | signal(SIGINT, istat); | |
518 | signal(SIGQUIT, qstat); | |
519 | signal(SIGHUP, hstat); | |
520 | return(status); | |
521 | } | |
522 | .P2 | |
523 | The calls to | |
524 | .UL signal | |
525 | make sure that no interrupts, etc., | |
526 | interfere with the waiting process; | |
527 | this is the topic of the next section. | |
528 | .PP | |
529 | The routine as written has the limitation that only one pipe may | |
530 | be open at once, because of the single shared variable | |
531 | .UL popen_pid ; | |
532 | it really should be an array indexed by file descriptor. | |
533 | A | |
534 | .UL popen | |
535 | function, with slightly different arguments and return value is available | |
536 | as part of the standard I/O library discussed below. | |
537 | As currently written, it shares the same limitation. |