On 12/11/12 2:31 PM, DJ Mills wrote: The first two have been covered in other messages.
> > 3) > The first two issues aren't THAT big of a deal, because you can simply not > worry about coproc's exit status and use wait's. That's the idea; the coproc command itself returns an indication of whether or not the process to execute the command was created successfully. > That leads me to the > third > and largest issue, which is that "NAME_PID" only appears to work properly > either when in an interactive shell or when there's no command between the > coproc and the wait. It's a race to see whether or not the coprocess exits and is reaped and cleaned up before wait executes. `false' is a very short-lived process, doesn't require an exec, and so I would expect the child to exit very quickly. The cleanup, which includes unsetting the coproc-specific variables, happens when the coprocess is reaped, not when the next one is created. You can avoid the error by using something like [ -n "$COPROC_PID" ] && wait "$COPROC_PID" but of course you lose the exit status that way. I will look at saving the coprocess pids in the shell's list of exited background jobs (or see whether they're being saved there already), so if you manage to save the coproc pid you will be able to find the exit status. There are also some race conditions with coproc creation and very short- lived processes; look at http://lists.gnu.org/archive/html/bug-bash/2012-10/msg00027.html for some additional details. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
