Bug 1029907

I'm not sure about this. Firstly, I don't think the man page should be seen as a definitive reference to all the dark corners of bash. However, both the man page and the GNU bash reference manual mention that process substitution is implemented via pipes where available - which execute asynchronously.

Bash is certainly a complex piece of code, which asks for some line what
is worth documentation to be drawn.  However when the behavior can cause
subtle problems down the line (in my case, it was GNU make that started
proceeding the final target with the dependency that should have already
been fully finished while it wasn't due to this *undocumented* behavior
of bash), it's reasonable to be explicit about it so as to prevent
unexplained surprises and hence bad user experience (see also
the refererred link with a similar bottom line).

> both the man page and the GNU bash reference manual mention that
> process substitution is implemented via pipes where available
> - which execute asynchronously.

Yes.  This does not imply whether the process behind the target pipe end
is being waited for (most of the combinations is admittedly excluded due
to SIGPIPE and similar scenarios), though.  E.g., standard pipe is
threated in the opposite way and still no doubts about "internal
producer-consumer asynchronicity" as opposed to "external life-time
asynchronicity", which is what I meant with the term (sorry for not
being precise).

Btw. only the "consuming" process substitution [>(list)] seems to be
affected (just like the example in [1]), unless the program reading from
"consuming" one [<(list)] closes stdin deliberately (e.g., "head -n1")
AND such producer can recover from SIGPIPE et al.  But haven't
experimented with this more.

s/unless the program reading from "consuming"/unless the program reading from "producing"

condnack upstream - we will see what upstream will say on this request for extending manpage.

Jan,

With bash-4.4 I see below line was added in the manual [1] :

"The process list is run asynchronously, and its input or output appears  as  a  filename."

I could not find link to upstream discussion. Should this be sufficient to resolve this bug ?

[1] https://www.gnu.org/software/bash/manual/html_node/Process-Substitution.html

You likely mean this thread from which I am linking actual suggestion
that materialized later on as you say:
https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00150.html

Definitely, that's an improvement.

I for one would, however, rather see bit more guiding statement, e.g.:

> The process list is run asynchronously (without any explicit
> life-time bounding with regard to the main process), and its input...

It would definitely make me think twice about the implications.

What do you think?

So as I understand, it is already documented, but it would be good to see how to improve the documentation.

Moving this bug to rawhide for further discussion.

I believe the documentation is sufficiently clear about behaviour of process substitution. Marking as resolved.