Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14820 > unrolled thread

Re: Strange behaviour from jobs -p in a subshell

Started byGreg Wooledge <wooledg@eeg.ccf.org>
First post2018-11-14 10:25 -0500
Last post2018-11-14 10:25 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Strange behaviour from jobs -p in a subshell Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-14 10:25 -0500

#14820 — Re: Strange behaviour from jobs -p in a subshell

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-11-14 10:25 -0500
SubjectRe: Strange behaviour from jobs -p in a subshell
Message-ID<mailman.4036.1542209157.1284.bug-bash@gnu.org>
> >>> Consider the following script. While the 3 sleeps are running, both jobs
> >>> -p and $(jobs -p) will print 3 PIDs. Once the 3 children are finished,
[...]

... hey, I think I just figured out the GOAL!

You want to run a whole bunch of jobs in parallel, but only 3 at a
time.  Right?  There are some solutions for that at
<https://mywiki.wooledge.org/ProcessManagement> (Advanced questions #4).

Our bot in IRC also suggests this example:

parallel() {
  local workers=$1 handler=$2 w i
  shift 2
  local elements=("$@")
  for (( w = 0; w < workers; ++w )); do
    for (( i = w; i < ${#elements[@]}; i += workers )); do
      "$handler" "${elements[i]}"
    done &
  done
  wait
}
parallel 5 md5 *.txt

Some of the examples on the wiki page have a stricter guarantee of
maintaining the number of jobs when their durations are unpredictable,
but I include the above example for completeness.  Choose whichever
solution you like best.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web