home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / uprog / p5 < prev    next >
Encoding:
Text File  |  1979-01-10  |  12.2 KB  |  538 lines

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