On Mon, Oct 5, 2026 at 5:19 AM Zachary Santer <[email protected]> wrote: > > I think there's a real bug report here, though. I modified the script > a bit more to chase that down.
I found some reasonable-ish ways to test other 'wait' invocations, and they all exhibit the same general behaviors I reported in the last email, so here's a new bug report. Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -g -O2 uname output: MSYS_NT-10.0-26300 ZackFramework16 3.6.10-3ea87a50.x86_64 2026-09-28 15:20 UTC x86_64 Msys Machine Type: x86_64-pc-cygwin Bash Version: 5.4 Patch Level: 0 Release Status: devel Commit: 7cfdb340d2 Description: - multiple background processes - 'wait' called from within a non-forking command substitution * In POSIX mode: Waits for each PID twice in every case except when the whole thing is nested within a single forking command substitution. In that case, there tends to be somewhat fewer than 16 waits for the 8 background processes. - 'wait -n -p' without PID arguments reports each PID through the varname argument twice. - With 'wait -n -p' with PID arguments, you have to remove the varname element from the list of PIDs provided to the next invocation of the 'wait' call. If you don't and the 'wait' command is working correctly, it will raise an error. After this invocation runs for each PID argument, 'wait -n -p' without PID arguments is called until it returns status 127. This loop runs once for each background process that was forked, showing the prior call with PID arguments still left some record in place for each background process. - With the standard 'wait' with one PID argument at a time, you can call it twice for each PID. It will raise an error only on the third call. * In default mode: Waits for each PID once in every case except when the whole thing is nested within a single forking command substitution. Looks like some PIDs aren't waited for, but only in the case of 'wait -n -p' without PID arguments, actually. I wouldn't have expected to need POSIX mode when job control is disabled and the 'jobs' command is not called. - 'wait -n -p' without PID arguments reports each PID through the varname argument once. - The 'wait -n -p' call without PID arguments following the loop where PID arguments are provided exits with code 127 the first time it's called. - It was stated that, in default mode, the standard 'wait' invocation taking one PID argument at a time is intended to continue to report the termination status of that background process forever. There was no sense in trying to test this behavior. Repeat-By: ./bash /path/to/wait_results_3.sh # runs in default mode ./bash /path/to/wait_results_3.sh <any argument at all> # runs in POSIX mode
wait_results_3.sh
Description: Binary data
