On 03/12/17 21:14, Chet Ramey wrote:
On 11/29/17 5:36 PM, Tobias Hoffmann wrote:
Description:
As stated in the man page, bash will only allow a single coproc at a time.
Thus, when a first coproc has already ended, a second one can be created.
This can e.g. be verified by commenting out the upper #sleep line, below.
Alternatively, you can remove the parens that start the subshell.
But if we start a subshell while the coproc still runs, then wait inside
the subshell
until the first coproc has ended and then try to start another coproc, bash
prints the
infamous warning:
./test_sp1.sh: line 10: warning: execute_coproc: coproc [11030:COPROC]
still exists
The process id 11030 does (verifyably - e.g. add `ps a`) not exist the time
the warning is printed.░
The question is how much to reset, and when to do it. A child process can
legitimately expect to inherit the coproc file descriptors from its parent
and read and write them under circumstances that have been valid
historically.
Well, there seem to be two types of subshells: Those spawned with (...
), &, or | -- and those coming from $(...) and <( ... ).
In both of them $COPROC[] and $COPROC_PID are available, but only in the
second kind you can actually use the file descriptors. In the first
kind, you'll get (e.g.)
${COPROC[1]}: Bad file descriptor
(i.e. does not work, as documented).
You can, however, make them available even in the first kind, by duping
them first, e.g. by using
exec {fd}>&${COPROC[1]}
I'm not sure whether using them directly in the first kind of subshell
is actually a good idea. Some things seem to work better when duping
them first, but I have not investigated those cases further.
Tobias
The pid will never be valid for waiting in the child, because
it's not a child of the current shell, but simply testing whether or not
the process is alive isn't sufficient.
I think the best thing to do is to invalidate the pid whenever a child
process invalidates the coproc FDs.
Chet
