Re: waiting for process substitutions

[Mark March]

 lastpipe takes effect only if job control is off. From the man page:

    lastpipe
                      If set, and job control is not active,  the  shell....
With laspipe on and job control off, 'wait' appears to wait for all process 
substitutions:
set +mshopt -s lastpipe
echo $'foo\nbar' | tee >(echo first ; exit 1) >(wc ; sleep 10 ; echo wc) >(tail 
-n 1; echo tail)wait

blocks for 10s under Bash 5.2.21.

Likely just a documentation bug.
-Mark

    On Saturday, June 29, 2024 at 07:52:34 PM PDT, Zachary Santer 
<zsanter@gmail.com> wrote:  
 
 On Sat, Jun 29, 2024 at 2:07 PM Oğuz <oguzismailuysal@gmail.com> wrote:
>
> There is a limit to the number of jobs Bash can remember, once it's exceeded 
> the oldest job is overwritten. Do we really want process substitutions to 
> count against that limit?

They might already. Now I'm wondering if the documentation just needed updating.

I'm afraid to report this as a bug, because it feels like something
that running bash in MSYS2 on Windows could be responsible for, but
here goes.

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe
-D_STATIC_BUILD
uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.5.3.x86_64
2024-06-03 06:22 UTC x86_64 Msys
Machine Type: x86_64-pc-msys

Bash Version: 5.2
Patch Level: 26
Release Status: release

Description:

So bash can wait on process substitutions.

1) When all child processes are process substitutions:
a. wait without arguments actually appears to wait for all of them,
not just the last-executed one, contradicting the man page.
b. A subsequent call to wait listing all child process pids
immediately terminates successfully.
c. If calling wait -n in the middle of all this, whether listing only
un-waited-on child process pids or all child process pids, it lists
all argument pids as "no such job" and terminates with code 127. This
is probably incorrect behavior.

2) When a standard background process is added:
a. wait without arguments waits for all child processes.
b. A subsequent call to wait listing all child process pids lists all
argument pids as not children of the shell and terminates with code
127. This seems incorrect, or at least the change in behavior from 1b.
is unexpected.
c. If calling wait -n in the middle of all this, we see that it only
lists the pids from process substitutions as "no such job".

Repeat-By:

./procsub-wait false false
./procsub-wait false true
./procsub-wait true false
./procsub-wait true true

procsub-wait and the results of running it on the listed system are attached.