On Mon, 22 Apr 2024, Martin D Kealey wrote:
On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote:
[…] I was saying the shell is crippled when limited to builtins; eg, a
read/printf loop compared to simply running cat.
I would hope that mapfile/readarray could do better, since it's not
obli
On Mon, 22 Apr 2024, Chet Ramey wrote:
You might be surprised. The OP was sending thousands of calculations to
(I think) GNU bc, which had some resource consumption issue that
resulted in it eventually hanging, unresponsive. The kill was the
solution there. I imagine there are similar scenar
On Mon, 22 Apr 2024, Martin D Kealey wrote:
On Sun, 21 Apr 2024, 10:13 Carl Edquist, wrote:
You mean, specifically in order to implement a slightly-more-efficient
'read' builtin in the shell?
The read built-in in the shell is only one case that would benefit from
such a sysc
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
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 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 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
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 t
On Tue, 16 Apr 2024, Andreas Schwab wrote:
But you can delimit your records on NULs, and use printf to reproduce
them.
Though that will likely add a spurious null at EOF.
On Tue, 16 Apr 2024, Zachary Santer wrote:
Just wouldn't copy over whatever might have followed the final null
byte, i
On Mon, 15 Apr 2024, Zachary Santer wrote:
As much as you can just printf the same thing once for each fd, that
doesn't work super well for binary data.
Well, you _can_ shovel binary data too: (*)
while IFS= read -rd '' X; do printf '%s\0' "$X"; done
and use that pattern to make a sh
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 example. As you understand, this model us
On Mon, 8 Apr 2024, Chet Ramey wrote:
On 4/4/24 8:52 AM, Carl Edquist wrote:
Zack illustrated basically the same point with his example:
exec {fd}< <( some command )
while IFS='' read -r line <&"${fd}"; do
# do stuff
done
{fd}<
On 4/4/24 7:23 PM, Martin D Kealey wrote:
I'm somewhat uneasy about having coprocs inaccessible to each other. I
can foresee reasonable cases where I'd want a coproc to utilize one or
more other coprocs.
In particular, I can see cases where a coproc is written to by one
process, and read fro
Hi Chet, thanks for taking the time to review this :D
[My apologies again upfront for another lengthy (comprehensive?) email.]
On Wed, 3 Apr 2024, Chet Ramey wrote:
On 4/2/24 12:22 PM, Carl Edquist wrote:
the forked coproc has to close its fds to/from _all_ other existing
coprocs (as
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 -
, 11 Mar 2024, Zachary Santer wrote:
Was "RFE: enable buffering on null-terminated data"
On Mon, Mar 11, 2024 at 7:54 AM Carl Edquist wrote:
(Kind of a side-note ... bash's limited coprocess handling was a long
standing annoyance for me in the past, to the point that I wrote a
2 Jul 2016, Chet Ramey wrote:
On 7/11/16 6:02 PM, Carl Edquist wrote:
Bash Version: 4.3
Patch Level: 46
Release Status: release
Description:
The docs say:
Bash handles several filenames specially when they are
used in redirections, as described in the following table:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown'
-DLOCALEDIR='/scratch/edqui
18 matches
Mail list logo
