Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!princeton!phoenix!vic
From: vic@phoenix.Princeton.EDU (V Duchouni)
Newsgroups: comp.unix.questions
Subject: Re: C-shell idiosyncracy ??
Message-ID: <1112@phoenix.Princeton.EDU>
Date: Fri, 13-Nov-87 01:14:20 EST
Article-I.D.: phoenix.1112
Posted: Fri Nov 13 01:14:20 1987
Date-Received: Sun, 15-Nov-87 03:45:49 EST
References: <33414@sun.uucp> <9316@mimsy.UUCP>
Reply-To: vic@phoenix.UUCP (V Duchouni)
Organization: Princeton Univ. Computing and Information Technology
Lines: 47

In article <9316@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <33414@sun.uucp> vipin%samsun@Sun.COM (Vipin Samar) writes:
>>{samsun} jobs
>>[1]  + Stopped		emacs foo
>>{samsun} jobs > bar
>>{samsun} cat bar
>>[1]  + Stopped		emacs foo
>>{samsun} jobs | more
>>{samsun}
>>
>>So, for some reasons I just cannot pipe the output of "jobs".
>
>To see why this happens, consider how pipes are implemented.
>After creating a pipe, it is necessary to fork.  A fork is
>not the parent of any of its parent's processes, hence a
>forked sub-C-shell must forget all its parent's jobs.

     Well, it is not strictly necessary (but very advisable) to fork,
     that is for the command:

machine% built_in | binary

   one migh hope that the shell would fork only once, spawning
   "binary" and execute built_in followed by a wait() , with output to the pipe,
   (potentially stopping if the pipe fills up, ouch!!! One would
   find the shell dead on every instance of a wrong or buggy filter ) in this
   case "jobs | cat" would work. 

   Instead the shell also (v?)forks (as it would for "binary1 | binary2")
   and the child (csh) ( which gets a copy of all internal variables,
   hence "alias | cat" as above) executes the built in and exits,
   while the parent waits for the exit of "binary". Here if
   binary is stupid and refuses to read, you will get impatient
   type ^C, and bingo "binary" dies, and the parent takes control.

   It looks like the shell needs some help from the kernel in
   determining the number of current jobs that are still alive
   ( remember if you typed jobs, and the shell was running
   it cannot have been waiting for its children and they may have
   died in the interim ), so while the shell knows the pids and 
   job numbers of its children ( and hence so does the child executing
   "jobs" in "jobs | cat" ) the child seeks current info on the jobs
   IT has spawned and finds none!

   This is perhaps disappointing, but it avoids disaster.

 V. Duchovni: email:		vic@fine.princeton.edu