Mike Coleman wrote: > I notice that if I do this in one (interactive) shell > > $ for n in 1 2 3 4 5; do /bin/sleep 60; echo $n; done > > and then 'kill -STOP' the sleep process (from another window), that > bash will proceed to run the next loop iteration. That is, it echos > '1' and starts a new /bin/sleep, even while the first one is sitting > there stopped. (This doesn't appear to be specific to 'sleep'--an > example with 'dd' also does the same thing.) > > It seems to me that this loop should just wait until the process is > 'kill -CONT'ed and keep right on going as if nothing had happened. Is > there any reason not to do this?
Ummm...yes. It renders job control useless. If we have the shell hang until a stopped child process is continued, why run with job control at all? If you want to treat the entire loop as a stoppable unit, run it in a subshell. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
