I've just stumbled upon the asynchronicity as per the summary. I found the explanation not in the manual, but rather after some search at [1]. Would be nice if the manual provided more definitive answers also at more advanced topics. [1] http://stackoverflow.com/a/4493552
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.