On Fri, Aug 09, 2024 at 15:20:52 -0400, Zachary Santer wrote: > On Fri, Aug 9, 2024 at 2:52 PM Greg Wooledge <g...@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.
