Re: exit value of intermediate program in pipe

["Bart Schaefer" <schaefer@brasslantern.com>]

On May 4,  2:03pm, Bernd Eggink wrote:
} Subject: Re: exit value of intermediate program in pipe
}
} Bart Schaefer wrote:
} 
} > } In ksh, the normal way to kill a coproc is
} > }
} > }   exec 3<&p 3<-
} > 
} > Anyway, I'm curious about that ksh-ism, because
} > it closes the coproc's *output*, not it's input 
} 
} Huh? Of course it closes it's input; that's what < means! 

Think about it a moment.  If you do

	cat <&p

what happens?  The input _of cat_ is connected to the _output_ of the
coproc, right?  So if you do

	exec 3<&p

then what is descriptor 3?  That better be the _output_ of the coproc,
too, or ksh is doing some pretty funky special casing.

So perhaps you meant to say

	exec 3>&p 3>-

??

} > Can somebody out there who has ksh tell me whether
} > 
} >         cat |&
} >         echo >&p
} > 
} > causes cat to exit?  That is, does redirection to the coproc make the
} > coproc input no longer available to any other process?  
} 
} Yes, it does.

OK, then zsh either has a bug or an undocumented feature.  If zsh did as
ksh does, then zsh's coproc would get EOF as soon as the first thing you
redirected to it exited.

} > } You can have more than one coprocs at a time. Just copy the fd's:
} > }
} > }   coproc f
} > }   exec 3>&p 4<&p   # or whatever numbers you like
} > }   coproc g
} > 
} > Right; if you do that, then my "coproc exit" trick won't stop the first
} > coproc, because its input has already been dup'd once and the dup is
} > kept open.
} 
} So in this case 'kill' seems to be the only way to get rid of the first
} n-1 coprocs...

No, that's not true.  Once you've run "coproc g" then you can get "f" to
see EOF by simply closing fd 3.  It's only the coproc descriptor that gets
copied rather than "moved" when you redirect it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com