On 6/29/24 10:51 PM, Zachary Santer wrote:
They might already. Now I'm wondering if the documentation just needed updating.
It might, but maybe not how you think. See below.
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.
No, it's not MSYS-specific.
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.
This is how it is in bash-5.2. It does contradict the man page, and I reverted it to match the man page in October, 2022, after https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html The whole business is kind of a mess. Let's see if we can figure out the best behavior. Through bash-4.4, `wait' without arguments didn't wait for process substitutions at all. I changed bash in 12/2017 to wait for all procsubs in addition to explicitly waiting for the last process substitution if its pid was the same as $!, mostly the result of this discussion: https://lists.gnu.org/archive/html/bug-bash/2017-12/msg00002.html and that change was in bash-5.0. The man page didn't change until 06/2019. There were some bug reports about this behavior, e.g., https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00000.html In bash-5.1 I added code to treat process substitutions more like jobs, even though they're not, in response to this use case: https://lists.gnu.org/archive/html/bug-bash/2019-09/msg00021.html so you were then able to wait for each process substitution individually, as long as you saved $! after they were created. `wait' without arguments would still wait for all process substitutions (procsub_waitall()), but the man page continued to guarantee only waiting for the last one. This was unchanged in bash-5.2. I changed the code to match what the man page specified in 10/2022, after https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html and that is what is in bash-5.3-alpha. The other thing that wait without arguments does is clear the list of remembered asynchronous pids and statuses. But process substitutions don't count against this (they probably should), so you've waited for the process substitutions and remembered their statuses. Bash should probably clear the list of reaped process substitutions before wait without arguments returns. But it doesn't do that yet.
b. A subsequent call to wait listing all child process pids immediately terminates successfully.
See above. `wait' finds the pids and exit statuses in the list of reaped procsubs. This is probably wrong: they should probably be cleared when `wait' runs without arguments,
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.
We've discussed this before. `wait -n' waits for the next process to terminate; it doesn't look back at processes that have already terminated and been added to the list of saved exit statuses. There is code tagged for bash-5.4 that allows `wait -n' to look at these exited processes as long as it's given an explicit set of pid arguments.
2) When a standard background process is added: a. wait without arguments waits for all child processes.
Same.
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.
It's different. The reaped background process triggers the cleanup of all background processes, including cleaning out the list of reaped procsubs. This is what doesn't happen, but probably should, in case 1.
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".
Same.
So the upshot is that bash should probably manage process substitutions
even more like other asynchronous processes in that the pid/status pair
should be saved on the list of saved exit statuses for `wait' to find it,
and clear that list when `wait' is called without arguments.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
