Re: Several issues with coprocesses regarding exit status

[DJ Mills]

On Thu, Dec 13, 2012 at 3:42 PM, Chet Ramey <chet.ramey@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    chet@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