| 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. |