Re: kill the LHS command of a pipe once the RHS command terminates

[Bart Schaefer <schaefer@brasslantern.com>]

On Mon, Jul 29, 2019 at 1:50 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> > > Concerning the documentation, the zshexpn(1) man page does not say
> > > that a process in process substitution is run in background.
> >
> > They have to be, otherwise either you'd need unlimited buffering or
> > the read of the descriptor could deadlock.
>
> I don't see how this is related to buffering. This would be the same
> case as with a pipe (cmd1 | cmd2), for which both commands run in
> foreground and there are no buffering issues.

You're wrong about this.  In (cmd1 | cmd2), zsh forks off cmd1 into
its own process.  It is effectively "in the background" even though
the entire pipeline is considered to be in the foreground; the only
process that is really "in the foreground" is cmd2.  If cmd2 stops
reading its stdin, cmd1 will eventually either block or get a SIGPIPE.

If both processes were in the foreground, they could get into a state
where neither can make any progress.  The same is true with <(...).

(Aside, in bash/ksh93 (cmd1 | cmd2) puts cmd2 in a forked process
instead, and keeps cmd1 in control.)

> It says that jobs explicitly put into the background are run
> asynchronously, but nothing about the converse.

I'm not sure how you get "nothing about the converse" from "Certain
jobs are run asynchronously  ... OTHER THAN THOSE explicitly put into
the background;" ("other than" refers to "certain jobs" that are
asynchronous but "(not) explicitly" backgrounded) and "Examples of
such asynchronous jobs are process  substitution" ... but in any case
this was one of those cases where the zsh manual assumed you know how
"most" shells work and therefore what these terms mean, and that it
only had to explain what it might be doing differently.  The whole
manual page used to be written this way and we are only gradually
turning it into a standalone reference.