Glenn Morris wrote: > Hi, > > This is a question similar to one from September 2006: > > http://lists.gnu.org/archive/html/bug-bash/2006-09/msg00077.html > > > Using bash 3.2.39 on x86_64 RHEL5.2, I have a script with contents: > > > function bar () > { > sleep 10 & > pid=$! > exec 3>&2 2>/dev/null > kill $pid > # usleep 1 > exec 2>&3 3>&- > } > > bar > > > If I run this script 1000 times via a loop, I get a handful of messages > (the number varies) of the form: > > /path/to/script: line 14: 10327 Terminated sleep 10 > > If I uncomment the "usleep" line, I get no such messages at all. > > If I comment out the usleep and both exec lines, I get a handful of messages. > > If I then uncomment the usleep line, I get 1000 messages.
This is a classic race condition. The timing of the message depends on when bash sends the signal to the subprocess, when the kernel schedules the subprocess to run and posts the signal, when the subprocess runs, receives the signal and exits, and when bash receives notification of the child process's death. > Hence, some questions: > > 1) Shouldn't the production of the "terminated" message be deterministic? No. It's a race between the shell restoring stderr (or exiting) and the subprocess exiting. If you want determinism, use `wait'. > 2) Why does sleeping make a difference? It changes the timing so the parent shell is still around when the child exits. > 3) Is there a "right" way to suppress the "terminated" message? You're doing it right -- the shell prints the messages to its own stderr -- but you need to make sure the child process has exited before you assume it has and restore the fd. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
