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


Groups > gnu.bash.bug > #14820

Re: Strange behaviour from jobs -p in a subshell

From Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups gnu.bash.bug
Subject Re: Strange behaviour from jobs -p in a subshell
Date 2018-11-14 10:25 -0500
Message-ID <mailman.4036.1542209157.1284.bug-bash@gnu.org> (permalink)
References <b17b162c-9f60-37fc-2473-30e267a681d2@st-andrews.ac.uk> <563c6188-c905-db81-f330-b79bf17e4413@case.edu> <6eaf7fe8-eb1b-7f90-45f9-364d8c426f39@st-andrews.ac.uk> <429c0789-1917-449d-f570-cc5c74141535@case.edu>

Show all headers | View raw


> >>> 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.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web