>> It knows that *process* C is gone.  It doesn't know whether *pgrp* C
>> is gone or not.  [...]

>>> The situation is really more interesting when the shell forks a
>>> pipeline, but this is not the situation here.
>> Oh, there may be other processes in the pgrp, but that's not very
>> relevant.  If any of them are still alive (or dead but unreaped),
>> the pgrp is still around, and B knows it.
> Well, you usually don't end up in a situation where you want to put a
> process in an existing process group.

Usually?  Maybe not - I have no experience actually _using_ this shell
yet.  But it will happen often enough that I want to make sure it works
right.

> For example when you fork a pipeline, you can make the last process
> in the pipeline be the parent of all other processes.  If you do
> that, then this process will still be around after after the other
> processes in the pipeline have been reaped.

That's not acceptable because it means the shell can't tell when those
other processes die.  This is a problem both for user interaction (you
can't show the user their status) and because if that last process dies
early you can't block waiting for the others to die before considering
the pipeline complete.

My "new shell" is not yet another sh/csh/whatever clone.  I'm trying to
do something at least somewhat new, and it involves putting new
processes into existing process groups in enough non-pathological cases
that I want to make sure I do it right.  I'll be happy to make my
current design document available if you're interested.

> Even if you killed that process so that it died before the processes
> in the previous pipeline stages did, you really don't need to put
> those processes in the proper process group...

They need to be in the proper process group so that the correct sets of
processes get tty-generated signals, if nothing else.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B