On Mon, 1 Apr 2024, Chet Ramey wrote:
On 4/1/24 3:24 PM, Chet Ramey wrote:
On 3/14/24 5:58 AM, Carl Edquist wrote:
Well, *without multi-coproc support*, here's a simple wc example; first
with a single coproc:
$ coproc WC { wc; }
$ exec {WC[1]}>&-
$ read -u ${WC[0]} X
$ echo $X
0 0 0
This works as expected.
But if you try it with a second coproc (again, without multi-coproc
support), the second coproc will inherit copies of the shell's read and
write pipe fds to the first coproc, and the read will hang (as described
above), as the first coproc doesn't see EOF:
$ coproc WC { wc; }
$ coproc CAT { cat; }
$ exec {WC[1]}>&-
$ read -u ${WC[0]} X
# HANGS
But, this can be observed even before attempting the read that hangs.
Let's see if we can tackle these one at a time. This seems like it
would be pretty easy to fix if a coproc closed the fds corresponding
to an existing coproc in the child after the fork. That wouldn't
really change anything regarding how scripts have to manually manage
multiple coprocs, but it will prevent the shell from hanging.
I sent this before I was ready. This would be equivalent to changing the
commands to use
coproc CAT { exec {WC[0]}<&- {WC[1]}>&- ; cat; }
but the script writer wouldn't have to manage it.
Agreed.
And just to note two things (in case it wasn't clear) - (1) the above
example that hangs is with the default bash, compiled _without_
multi-coproc support; and (2):
This seems like it would be pretty easy to fix if a coproc closed the
fds corresponding to an existing coproc in the child after the fork
the forked coproc has to close its fds to/from _all_ other existing
coprocs (as there can be several).
Carl
