Re: tcsh being dodgy, or pipe code ishoos?

John-Mark Gurney wrote:
> ok, with some magic ktrace work, I have come up with an more complete
> answer to the riddle.  It's how the shell exec's the processes.  The
> bare cause can be demo'd by:
> 
>>( ( echo 2 ; echo 3 ) | ./xargs -I% echo + % )
> 
> 
> Say the shell you run the above command is 10.  It will fork to create
> a shell to run the commands in the outter parens.  Call this 11.  11's
> job is to run: (echo 2; echo 3) | ./xargs -I% echo +%
> 11 will fork/exec and run: echo 2; echo 3 creating process 12.  11
> will see that there is no additional commands after ./xargs, and
> exec (not fork) xargs.  Since 12 is stil around and a child of 11,
> when it exits, 11 will reap 12, and thinking that the first proccess
> has exited, run the second echo command.  Due to scheduling, we'll
> have two processes running at the same time which can cause the
> interleaving of data.
> 
> So, now the question is, do we fix xargs to deal with unexpected
> children?  Or fix the shells in question?  (tcsh and zsh seem to suffer
> this problem)
> 
> To me, fixing xargs is correct since it prevents another possible
> future abusers of this "feature".

Good work!  Congratulations on figuring that one out.

It's probably best to fix both.  Fixing xargs basically
involves keeping a list of child PIDs and checking harvested
children against that list.  If the child wasn't spawned by xargs,
it should just ignore it (in particular, not decrement curprocs).  Not
entirely trivial, but not a lot of work, either.

Fixing the shell would also be desirable, as Terry points
out, though it does involve removing a nice optimization.
Why do exec-ed processes inherit the children of the former
process, anyway?  That doesn't entirely sound right to me.
Is that behavior mandated by some standard?  If not, this
could arguably be considered a kernel bug.  Hmmm...

Tim Kientzle