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
scenarios with other tools.
Ok, you got me! I take it back.
I hadn't considered bc operations being cpu/memory intensive. But that
possibility makes sense - given that it's arbitrary precision I guess you
can ask for a number to the billionth power and never see the end of it :)
Carl
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 the same page.
My original intention for the coprocs (and Korn's from whence they came)
was that the shell would be in the middle -- it's another way for the
shell to do IPC.
And coprocesses are great for this, too!
It's just that external commands in a sense are extensions of the shell.
The arms and legs, you might say, for doing the heavy lifting.
Carl
e tokenizing in userspace. And with any luck you can
find an appropriate command line utility to do that for you, rather than
relying on the shell's 'read' builtin.
(Or for your own programs, use getline(3)/getdelim(3), as Chet mentioned.)
Carl
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
shell is really crippled if
the close-on-exec flags prevent external programs from accessing manual
copies of other coproc fds.
Carl
[1] eg:
emergency_maxbuf_cat_monster () (
maxbuf=${1:-4096}
fmts=('%s' '%s\0')
while IFS= read
g pipelines like this, but
I've never had a reason to.
"If you build, it they will come." ;)
Carl
ere is the `fdflags' loadable builtin you can experiment with to
change close-on-exec.
Thanks for the tip. It's nice to know there is a workaround to leave
copies of the coproc fds open across exec; though for now I will probably
continue setting up pipes in the shell by methods other than the coproc
keyword.
Cheers,
Carl
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}<
But
once you have the freedom to play with it, you find more interesting,
useful applications.
Of course, for the above technique to be generally useful, external
commands need access to these user-managed fds (copied with exec). (I
have no idea why the coproc shell closes them.) The shell is crippled
when limited to builtins.
(I'll try to tidy up some working examples with my coprocess management
library this week, for the curious.)
Juicy thread hey? I can hardly keep up! :)
Carl
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
Nevermind! I was misunderstanding what the 'command' builtin does!
Thank you,
Carl
> On 5/17/2021 3:40 PM Carl Thompson wrote:
>
>
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
>
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/ba
(I'm sending this request to bug-bash since that's what the GNU/bash
documention said to do.
I'm also CC'ing the lmod-users community since this would be of interest
to them.
I don't know how broadly you would want to reply to this.)
I use #!/bash -eux in almost all my scripts, so I can quickly
act work.
I suppose it's worth saying something about how bash emulates the files
on systems that don't provide the feature themselves.
Sure! Yeah, that sounds like it would convey both the intention and the
actual behavior.
Thanks for your time & consideration!
Carl
On Tue, 1
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
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
Hello folkz ?!
please check out if bash 3.2.0 is broken ???
as root after TAB-TAB only 2178 possibilities are shown ???
Should be about 3.300 possibilities, or not ???
Greetings.
Carl.
the $PATH gets updated.
Why does ubuntu provide the .bash_profile when a user is created, and then not
source it when the system starts up? And since it doesn't, what do I change to
make it happen?
Bob Proulx <[EMAIL PROTECTED]> wrote: Carl Wenrich wrote:
> echo $0 gives me "ba
echo $0 gives me "bash"
echo $- gives me "himBH"
Bob Proulx <[EMAIL PROTECTED]> wrote: Carl Wenrich wrote:
> Bob Proulx wrote:
> > Did you log in after having made that change? Was bash invoked as
> > an interactive login shell so that it would read
Yes. I (1) made the change to .bash_profile, then (2) restarted the machine,
then (3) logged in again. When I echo $PATH the /opt/lampp/bin is not included.
Bob Proulx <[EMAIL PROTECTED]> wrote: carlwenrich wrote:
> I put this in my .bash_profile:
>
> PATH=$PATH:/opt/lampp/bin
> export PATH
>
>
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/s
27 matches
Mail list logo
