Please let me thank everyone for their kind attention and thoughtful remarks on this problem ... I am struggling however to summarize the discussion so far ... specifically in regard to workarounds. To date, the sole suggested workaround is:
The fix for your case is to insert `wait' without arguments after the call to mapfile and before the sleep. That way you ensure that the 'wait -n' waits for the sleep process. Hmmm ... yes, the suggested workaround does patch the minimal working example (MWE). But it is NOT a general-purpose workaround. As a concrete---and common-place---example, I use bash-scripts to run (asynchronously) cpu-intensive optical-character-recognition (OCR) processes. On my system, optimal cpu-loading is achieved when no more than five OCR processes are running. So I initialize an array PIDS with the job-ids of the asynchronous OCR processes that presently running. Various initialization methods work; the following is a general-purpose one-liner: mapfile -t PIDS < <(jobs -rp); # initialize PIDS (by any method) Then at any later time (possibly after further housekeeping tasks), and immediately prior to launching another (asynchronous) OCR process, issue JOB_LIMIT=5 ((${#PIDS[@]}<JOB_LIMIT)) || wait -n "${PIDS[@]}"; QUESTION: given an array PIDS containing (cpu-intensive) job-ids, what (all-settings?) bash-workaround replaces the above { wait -n "${PIDS[@]}"; } command? PS: Thank you especially, Chet Ramsey, for the smile-inducing quotes from Chaucer and Hippocrates in your email signature. BIOLOGICALS FOREVER !!! :)