Re: 'wait -n' with and without id arguments

[Greg Wooledge]

On Fri, Aug 09, 2024 at 15:20:52 -0400, Zachary Santer wrote:
> On Fri, Aug 9, 2024 at 2:52 PM Greg Wooledge <greg@wooledge.org> wrote:
> >
> > The problem is that our entire understanding of what "wait -n" DOES has
> > been annihilated.  We thought it would "trigger" exactly once for every
> > completed background process, regardless of whether they completed
> > before or after calling "wait -n", which would allow the writing of an
> > N-jobs-at-a-time thing.  It turns out this is incorrect.
> 
> My understanding is that it actually does this reliably, but only when
> it's in a script. The attached was basically my take on your example,
> obviously with infinite dummy tasks and sleeping in the parent shell.
> Feel free to mess around with it. The loop only terminates when the
> script is sourced from the interactive shell.
> 
> If it wasn't made clear in the earlier discussion that what bash is
> doing that makes this unreliable is only a factor in the interactive
> shell, then I wasn't the only one missing something.

If that's true, then there are *two* things to complain about.  First,
that the "wait -n" behavior is surprising, in a very bad way.  Second,
that something changes in a subtle and *incredibly* hard to pinpoint way
between interactive and non-interactive shells.

Hell, let's call it three things to complain about.  Third, that there
is no documentation that explains any of this clearly.