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
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 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 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,
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
