On Tue, Jul 15, 2025 at 06:52:14 -0400, Zachary Santer wrote:
> On Mon, Jul 14, 2025 at 10:52 PM John Sidles <jasid...@gmail.com> 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.
My first thought when looking at "wait -n $pid" is that it's nonsense,
but it turns out you're correct. "help wait" says
If the -n option is supplied, waits for a single job from the list of IDs,
or, if no IDs are supplied, for the next job to complete and returns its
exit status.
So, either the help text is wrong, or the behavior is wrong, because
they don't match.
In this particular case, you can work around the issue by not using
the -n option in the first place, since it's just unneeded with a single
$pid argument.
