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