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 find the deli
On Wed, 17 Apr 2024, Chet Ramey wrote:
On 4/15/24 1:01 PM, Carl Edquist wrote:
Yet another point brought to light by the bcalc example relates to the
coproc pid variable. The reset() function first closes the coproc
pipe fds, then sleeps for a second to give the BC coproc some time to
fin
On Wed, 17 Apr 2024, Chet Ramey wrote:
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 terminated.
Oh, nice! :)
Carl
On Thu, 18 Apr 2024, Martin D Kealey wrote:
On Wed, 17 Apr 2024, Chet Ramey wrote:
It has to do it that way to find the delimiter on a non-seekable file
descriptor, since it has to leave everything it didn't consume
available on stdin.
Has anyone tried asking any of the kernel teams (Linux,
On Tue, 16 Apr 2024, Chet Ramey wrote:
The bigger concern was how to synchronize between the processes, but
that's something that the script writer has to do on their own.
Right. It can be tricky and depends entirely on what the user's up to.
My concern was always coproc fds leaking into ot
