On Thu, Dec 13, 2012 at 3:42 PM, Chet Ramey <chet.ra...@case.edu> wrote:
> 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/ > Great, thanks for the clarification. The actual use case is as follows: coproc cowout { "${cower[@]}" --color=never -uq; } while read -ru "${cowout[0]}" pkg; do targets+=("$pkg") done if ! wait "$cowout_PID"; then die "cower error" fi Again, the whole idea is to be able to both read the ouptut in the current shell and check the exit status. A race condition shouldn't be an issue there, obviously, since it's not going to exit until the loop finishes. So with the change you suggested there, a simple: cower_pid=$cowout_PID # before the while read loop should suffice. Thanks again, DJ
