Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site masscomp.UUCP Path: utzoo!watmath!clyde!bonnie!masscomp!leiby From: leiby@masscomp.UUCP (Mike Leibensperger) Newsgroups: net.unix-wizards,net.bugs.usg Subject: Re: Shell out bug in pg (but a more general problem) Message-ID: <641@masscomp.UUCP> Date: Mon, 11-Mar-85 20:30:27 EST Article-I.D.: masscomp.641 Posted: Mon Mar 11 20:30:27 1985 Date-Received: Tue, 12-Mar-85 03:36:25 EST References: <12@istbt.UUCP> <562@rlgvax.UUCP> Reply-To: leiby@masscomp.UUCP (Mike Leibensperger) Organization: Masscomp - Westford, MA Lines: 20 Xref: watmath net.unix-wizards:12399 net.bugs.usg:192 Summary: What is rational for sh's strange pipeline forking behavior? In article <562@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: >Code which starts up a child process and does a general "wait" for any >children without checking that the child they're interested in is what >exited is broken, due, as you mentioned, to the fact that the shell's >way of setting up pipelines creates unexpected edges in the family >tree of processes. Does anyone know what the rational was/is for having the shell create pipelines in this seemingly ludicrous way (i.e. the Nth process in the pipeline is parent of the (N-1)st)? After all, why should a program need to concern itself with the process behaviour of previous programs in its pipeline? It just rubs me the wrong way. If someone could enlighten me about the rational for this change, and about when the change first appeared, I would appreciate it. The 'r' key is sufficient.... -- Mike Leibensperger Masscomp; 1 Technology Park; Westford, MA 01886 {decvax,harpo,tektronix}!masscomp!leiby