Re: process substitution bug with set -e?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 15,  9:42am, Peter Stephenson wrote:
}
} What scope should be trying to cover here?  Simply document for process
} substiution that if the code to which the substitution applies exits
} early the shell won't wait for it to finish?  Or can we infer something
} a bit wider?

I think we should be able to say something more general about the behavior
of "exit" with respect to asynchronous jobs, and that ERR_EXIT has the
same behavior.  There's a little about this in the "Jobs" section but it
only references explicitly backgrounded jobs and the HUP signal/option,
not about implicitly asynchronous jobs.

For example, note that multios and process substitutions are "disowned"
in the sense that they don't get HUP'd (they also don't get TTOU'd, but
aren't able to read from the terminal as far as I can tell [I/O error]).

We could further explain the generality that any pair of jobs that act as
a reader and a writer -- multios, process substitutions, pipes, are there
more? -- have to be run in parallel to avoid deadlock, which means that
at least one of each such pair is "implicitly asynchronous" in the sense
I used above.  Yeah, that's a misuse of "implicit" because the user has
of course explicity written >>(...) or whatever, so maybe there's another
way to say it.

I suppose the tail end of the "Jobs" section is the right place to put
this, even though that's somewhat distant from the descriptions of the
syntax that evoke the behavior.