" If n is not given, all currently active child processes are waited for, and the return status is zero." So it's not necessary to add a "wait" for each process, one wait covers all of them. I'm not clear on how you would specify a process to wait for, as you'd have to determine it's PID, but I don't care right now, and I know I've seen code to check for a PID. > -----Original Message----- > From: david nicol [mailto:whatever@davidnicol.com] > Sent: Monday, July 22, 2002 7:40 PM > To: Jonathan Hutchins > Cc: kclug@kclug.org > Subject: Re: Parallel Tasks > > > Jonathan Hutchins wrote: > > > > To take it to the next level, how do I: > > > > Start three tasks in parallel, then > > > > Wait until all three have completed before taking the next step? > > > majordomo@kclug.org > > > from bash(1): > > wait [n] > Wait for the specified process and return its ter­ > mination status. n may be a process ID or a job > specification; if a job spec is given, all pro­ > cesses in that job's pipeline are waited for. If n > is not given, all currently active child processes > are waited for, and the return status is zero. If > n specifies a non-existent process or job, the > return status is 127. Otherwise, the return status > is the exit status of the last process or job > waited for. > > > so you could do > > checklinks site1 & > checklinks site2 & > checklinks site3 & > checklinks site4 & > > # one wait for each backgrounded checklinks > wait > wait > wait > wait > > > I believe it is slightly superior to have each backgrounded process > clean up after itself than to depend on wait, because it is > easy to add > a new site and forget to add a new "wait" for instance. So you could > launch > all the checkers at 3 pm and launch the check-log-analyzer at 9 pm and > still > have daily log analysis. >