Some other way of thinking:
> On 3/14/24 5:58 AM, Carl Edquist wrote:
> > ...
> > But if you try...
> >
> > $ coproc WC { wc; }
> > $ coproc CAT { cat; }
> > $ exec {WC[1]}>&-
> > $ read -u ${WC[0]} X
> >
> > # HANGS
To prevent `exec {WC[1]}>&-` to close both FD, just
On 4/16/24 2:46 AM, Carl Edquist wrote:
But the shell is pretty slow when you ask it to shovel data around like
this. The 'read' builtin, for instance, cautiously does read(2) calls of a
single byte at a time.
It has to do it that way to find the delimiter on a non-seekable file
descriptor,
On 4/15/24 1:01 PM, Carl Edquist wrote:
On Sat, 13 Apr 2024, Chet Ramey wrote:
The original intent was to allow the shell to drive a long-running
process that ran more-or-less in parallel with it. Look at
examples/scripts/bcalc for an example of that kind of use.
Thanks for mentioning this e
On 3/14/24 5:58 AM, Carl Edquist wrote:
Separately, I consider the following coproc behavior to be weird, fragile,
and broken.
Yes, I agree that coprocs should survive being suspended. The most recent
devel branch push has code to prevent the coproc being reaped if it's
stopped and not termina
On Wed, 17 Apr 2024, Chet Ramey wrote:
> On 4/16/24 2:46 AM, Carl Edquist wrote:
>
> > But the shell is pretty slow when you ask it to shovel data around like
> > this. The 'read' builtin, for instance, cautiously does read(2) calls of a
> > single byte at a time.
>
> It has to do it that way to
