On Mon, Jul 14, 2025 at 10:52 PM John Sidles <[email protected]> wrote:
>>
>> I was a pretty big part of that discussion, and this looks broken to
>> me. If 'wait -n' is passed a list of pids, it shouldn't also be
>> waiting for other background processes that weren't passed to it as
>> arguments. Is that what you're saying it's doing?
$ set -o posix
$ mapfile -t JOBS < <(jobs -rp);
$ printf '%s\n' "${!}"
256
$ sleep 10 & wait -f -n -p waited_for "${!}"
[1] 257
$ printf '%s\n' "${!}"
257
$ printf '%s\n' "${waited_for}"
256
[1]+ Done
Alright, that's definitely what's going on. Chet, this is a bug, man.
This is never going to be what the user wants when they're passing
'wait -n' pid arguments.
> I have more than 100 posix-mode scripts that require the functionality
> (in words) "for 'PIDS' an array of background process IDs, please wait
> for at least one process to finish".
>
> Prior to bash 5.3, this functionality was provided (even in posix mode)
> by 'wait -n "${PIDS[@]}";'' ... this bash idiom worked GREAT.
>
> Now, in bash 5.3, this 'wait -n' functionality still works fine ... EXCEPT
> in posix-mode. Huh?
>
> So, what's the bash 5.3 replacement for the prior posix-mode "wait -n"
> functionality?
At least for the time being, you're just going to have to not use
posix mode, or turn it off for your calls to 'wait'.
> Hopefully a replacement with comparable simplicity and programmatic
> naturality?
>
> At a minimum, can't "help wait" and "man bash" be amended to clarify
> these issues?
Details on the different behaviors implemented in posix mode are
available in bash's Info documentation, doc/bash.info, as well as in
the file POSIX at the root of bash's git repository. That said,
searching POSIX for 'wait', I'm not seeing anything that says this
would happen.
