Bug 1029907 - bash man page should document that process substitution won't wait for the process reprezenting the file descriptor to finish
bash man page should document that process substitution won't wait for the pr...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Siteshwar Vashisht
BaseOS QE - Apps
: ManPageChange
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-13 08:50 EST by Jan Pokorný
Modified: 2017-02-12 04:37 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-02-12 04:37:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pokorný 2013-11-13 08:50:27 EST
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
Comment 2 Ondrej Oprala 2013-11-14 02:26:42 EST
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.
Comment 3 Jan Pokorný 2013-11-14 07:42:55 EST
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.
Comment 4 Jan Pokorný 2013-11-14 07:47:08 EST
s/unless the program reading from "consuming"/unless the program reading from "producing"
Comment 5 Ondrej Vasik 2013-11-15 07:39:10 EST
condnack upstream - we will see what upstream will say on this request for extending manpage.
Comment 8 Siteshwar Vashisht 2017-01-18 11:40:31 EST
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
Comment 9 Jan Pokorný 2017-01-19 13:10:53 EST
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?
Comment 10 Siteshwar Vashisht 2017-01-31 06:51:51 EST
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.
Comment 11 Siteshwar Vashisht 2017-02-12 04:37:30 EST
I believe the documentation is sufficiently clear about behaviour of process substitution. Marking as resolved.

Note You need to log in before you can comment on or make changes to this bug.