Paul Jarc wrote:
> Jeff Miller <[EMAIL PROTECTED]> wrote:
>
>>It is possible on our test Solaris 8 system that the original
>>calling bash shell will set the controlling process of the terminal
>>to the pid that it originally forked to after the new process had
>>been created. In this case is not the new bash process. It happens
>>to do this after the new bash has done it's write but before it has
>>done it's read, this new process still assumes it is still the
>>controlling process.
>
>
> Chet, could the foreground process group be set by the forked child
> itself, before the exec, instead of by the parent? That would at
> least eliminate the race condition so the results would be
> predictable, and I think it would prevent the problem in this case.
It is. The terminal process group is set N+1 times in a N-stage
pipeline: once by each child, and once by the parent. This was
considered `best practice' by the POSIX people when I put it in.
I still think it's the best way to avoid problems.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
