Re: Examples of concurrent coproc usage?

On 4/27/24 12:56 PM, Carl Edquist wrote: 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

Readdelim (was Re: Examples of concurrent coproc usage)

On Sun, 28 Apr 2024, 05:03 Carl Edquist, wrote: > > > I would hope that mapfile/readarray could do better, since it's not > > obligated to leave anything in the input stream. > > That is an interesting thought, although mapfile seems to read a byte at a > time also. > > [I'm not suggesting this

Re: Examples of concurrent coproc usage?

On Sat, Apr 27, 2024 at 1:01 PM Carl Edquist wrote: > > On Mon, 22 Apr 2024, Martin D Kealey wrote: > > > On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote: > > > >> But yeah currently a pipe with a series of records and multiple > >> cooperating/competing readers perhaps only works if the records

Re: Examples of concurrent coproc usage?

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 obligated

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On 4/21/24 7:42 AM, Martin D Kealey wrote: On Sat, 20 Apr 2024 at 01:14, Chet Ramey > wrote: On 4/17/24 8:55 PM, Martin D Kealey wrote: > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) to > add a new system call such as

Re: Examples of concurrent coproc usage?

On 4/20/24 7:11 PM, Carl Edquist wrote: I could always enable it in the devel branch and see what happens with the folks who use that. It would be three years after any release when distros would put it into production anyway. Oh, fun  :) I'll enable it in the next devel branch push, so

Re: Examples of concurrent coproc usage?

On 4/20/24 6:04 PM, Carl Edquist wrote: I think this is _definitely_ true for the BC coproc in the bcalc example. But it's kind of a distraction to get hung up on that detail, because in the general case there may very well be other scenarios where it would be appropriate to, um, _nudge_ the

Re: Examples of concurrent coproc usage?

On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote: > When I say "token" I just mean a record with whatever delimiter you're > referring to using. Ok that makes sense. Assuming the reading stops after consuming the first delimiter (which is > necessary for the 'read' builtin), then you end up

Re: Examples of concurrent coproc usage?

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 syscall. The

Re: Examples of concurrent coproc usage?

On Sun, 21 Apr 2024, 10:13 Carl Edquist, wrote: > On Thu, 18 Apr 2024, Martin D Kealey wrote: > > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) > > to add a new system call such as readln() or readd()? > > You mean, specifically in order to implement a

Re: Examples of concurrent coproc usage?

On Sat, 20 Apr 2024 at 01:14, Chet Ramey wrote: > On 4/17/24 8:55 PM, Martin D Kealey wrote: > > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) to > > add a new system call such as readln() or readd()? > > They'd probably point you to an optimized version of

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On 4/17/24 8:55 PM, Martin D Kealey wrote: 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.

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On 4/12/24 12:49 PM, Carl Edquist wrote: Where with a coproc coproc X { potentially short lived command with output; } exec {xr}<&${X[0]} {xw}>&${X[1]} there is technically the possibility that the coproc can finish and be reaped before the exec command gets a chance to run and

Re: Examples of concurrent coproc usage?

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,

Re: Examples of concurrent coproc usage?

On Tue, Apr 16, 2024 at 3:56 AM Andreas Schwab wrote: > > On Apr 16 2024, Carl Edquist wrote: > > > 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 shell-only version of tee(1) (and I suppose >

Re: Examples of concurrent coproc usage?

On Apr 16 2024, Carl Edquist wrote: > 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 shell-only version of tee(1) (and I suppose > paste(1)). Binary data doesn't work if you're reading

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On Mon, Apr 15, 2024 at 1:57 PM Carl Edquist wrote: > > the thing discussed in my last email to the list (about > coproc fds being set close-on-exec) makes them unusable for anything > beyond stdin/stdout/stderr. > > [It might sound like an obscure use case, but once you realize what you > can do

Re: Examples of concurrent coproc usage?

On 4/14/24 2:43 PM, Zachary Santer wrote: On Sat, Apr 13, 2024 at 4:10 PM 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. $ ./bcalc

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

history: -1: invalid option history: usage: history [-c] [-d offset] [n] or history -anrw [filename] or history -ps arg [arg...] -12 equation: exit diff --git a/examples/scripts/bcalc b/examples/scripts/bcalc index bc7e2b40..826eca4f 100644 --- a/examples/scripts/bcalc +++ b/examples/scripts/bc

Re: Examples of concurrent coproc usage?

On Sat, Apr 13, 2024 at 2:45 PM Chet Ramey wrote: > > On 4/8/24 11:44 PM, Zachary Santer wrote: > > > The fact that the current implementation allows the coproc fds to get > > into process substitutions is a little weird to me. A process > > substitution, in combination with exec, is kind of the

Re: Examples of concurrent coproc usage?

Date:Sat, 13 Apr 2024 16:10:26 -0400 From:Chet Ramey Message-ID: <32bd9e76-24bc-4206-aa8a-8bcc81722...@case.edu> | File descriptors the user saves with exec redirections beyond [0-2] | are set to close-on-exec. POSIX makes that behavior unspecified, but | bash

Re: Examples of concurrent coproc usage?

On 4/9/24 11:58 AM, Carl Edquist wrote: 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

Re: Examples of concurrent coproc usage?

On 4/9/24 10:46 AM, Zachary Santer wrote: If you want two processes to communicate (really three), you might want to build with the multiple coproc support and use the shell as the arbiter. If you've written a script for other people than just yourself, expecting all of them to build their

Re: Examples of concurrent coproc usage?

On 4/8/24 11:44 PM, Zachary Santer wrote: The fact that the current implementation allows the coproc fds to get into process substitutions is a little weird to me. A process substitution, in combination with exec, is kind of the one other way to communicate with background processes through fds

Re: Examples of concurrent coproc usage?

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}<&- A process-substitution open to

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On Mon, Apr 8, 2024 at 3:50 PM Chet Ramey wrote: > > 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. > > That's not the intended

Re: Examples of concurrent coproc usage?

On Mon, Apr 8, 2024 at 11:07 AM Chet Ramey wrote: > > Bash doesn't close the file descriptor in $fd. Since it's used with `exec', > it's under the user's control. > > The script here explicitly opens and closes the file descriptor, so it > can read until read returns failure. It doesn't really

Re: Examples of concurrent coproc usage?

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. That's not the intended purpose, so I don't think not fixing a bug to accommodate some

Re: Examples of concurrent coproc usage?

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}<&- A process-substitution open to the shell like this is effectively a

Re: Examples of concurrent coproc usage?

On 4/3/24 1:19 PM, Zachary Santer wrote: On Wed, Apr 3, 2024 at 10:32 AM Chet Ramey wrote: How long should the shell defer deallocating the coproc after the process terminates? What should it do to make sure that the variables don't hang around with invalid file descriptors? Or should the

Re: Examples of concurrent coproc usage?

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 from by another. Can we at least have the

Re: Examples of concurrent coproc usage?

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

Re: Examples of concurrent coproc usage?

On Wed, Apr 3, 2024 at 10:32 AM Chet Ramey wrote: > > How long should the shell defer deallocating the coproc after the process > terminates? What should it do to make sure that the variables don't hang > around with invalid file descriptors? Or should the user be responsible for > unsetting the

Re: Examples of concurrent coproc usage?

On 3/14/24 5:58 AM, Carl Edquist wrote: HOWEVER!!! Unexpectedly, the new multi-coproc code seems to close the user shell's end of a coprocess's pipes, once the coprocess has terminated.  When compiled with MULTIPLE_COPROCS=1, this is true even if there is only a single coproc: $

Re: Examples of concurrent coproc usage?

On 4/2/24 12:22 PM, Carl Edquist wrote: This seems like it would be pretty easy to fix if a coproc closed the fds corresponding to an existing coproc in the child after the fork the forked coproc has to close its fds to/from _all_ other existing coprocs (as there can be several). And there

Re: Examples of concurrent coproc usage?

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 -u ${WC[0]} X   

Re: Examples of concurrent coproc usage?

On 4/1/24 3:24 PM, Chet Ramey wrote: On 3/14/24 5:58 AM, Carl Edquist wrote: But you can create a deadlock without doing anything fancy. Well, *without multi-coproc support*, here's a simple wc example; first with a single coproc:  $ coproc WC { wc; }  $ exec {WC[1]}>&-  $

Re: Examples of concurrent coproc usage?

On 3/14/24 5:58 AM, Carl Edquist wrote: But you can create a deadlock without doing anything fancy. Well, *without multi-coproc support*, here's a simple wc example; first with a single coproc: $ coproc WC { wc; } $ exec {WC[1]}>&- $ read -u ${WC[0]} X $ echo $X 0

Re: Examples of concurrent coproc usage?

On Thu, Mar 14, 2024 at 6:57 AM Carl Edquist wrote: > (And in general, latter coproc shells will have stray copies of the user > shell's r/w ends from all previous coprocs.) I didn't know that without MULTIPLE_COPROCS=1, bash wouldn't even attempt to keep the fds from earlier coprocs out of

Re: Examples of concurrent coproc usage?

[My apologies up front for the length of this email. The short story is I played around with the multi-coproc support: the fd closing seems to work fine to prevent deadlock, but I found one bug apparently introduced with multi-coproc support, and one other coproc bug that is not new.] On

Examples of concurrent coproc usage?

Was "RFE: enable buffering on null-terminated data" On Mon, Mar 11, 2024 at 7:54 AM Carl Edquist wrote: > > On Sun, 10 Mar 2024, Zachary Santer wrote: > > > On Sun, Mar 10, 2024 at 4:36 PM Carl Edquist wrote: > >> > >> Out of curiosity, do you have an example command line for your use case? > >

imprecise wording in builtin usage

In builtins.c, there is: "getopts optstring name [arg]" The "[arg]" should be replaced with "[arg ...]". In the same file there is: "exec [-cl] [-a name] [command [arguments ...]] [redirection ...]" The "arguments" should be replaced with "argument", since the "..." already says that there

Re: The usage of `cd builtins && $(MAKE) ...`

On 12/30/18 8:09 AM, Peng Yu wrote: > Hi, > > I see things like `cd builtins && $(MAKE) ...` in the Makefiles in > bash source code. GNU Make has the option of -C for entering a > directory and make. Is the reason to cd then make for compatibility > with other make's that don't support -C?

Re: The usage of `cd builtins && $(MAKE) ...`

Hi, > I see things like `cd builtins && $(MAKE) ...` in the Makefiles in > bash source code. GNU Make has the option of -C for entering a > directory and make. Is the reason to cd then make for compatibility > with other make's that don't support -C? Thanks. I'm afraid that you are in wrong

The usage of `cd builtins && $(MAKE) ...`

Hi, I see things like `cd builtins && $(MAKE) ...` in the Makefiles in bash source code. GNU Make has the option of -C for entering a directory and make. Is the reason to cd then make for compatibility with other make's that don't support -C? Thanks. -- Regards, Peng

Re: bash signal during wait + read causes unkillable 100% CPU usage

On 9/16/18 11:47 PM, hacke...@member.fsf.org wrote: > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > > I was trying to work around the problem of bash not being able to > cancel the read builtin command when a signal comes in and I stumbled > upon this (perhaps

bash signal during wait + read causes unkillable 100% CPU usage

responding and your CPU usage should go to 100%. The HUP, TERM and QUIT signals are ignored. - 8< - 8< - 8< - CUT HERE - 8< - 8< - 8< - #!/bin/bash trap cleanup EXIT cleanup() { echo "Huh. There was supposed to be an earth-shattering kab

Re: [PATCH] include ctype.h for isdigit usage

On 8/11/16 5:52 AM, Mike Frysinger wrote: > --- > lib/readline/histexpand.c | 1 + > 1 file changed, 1 insertion(+) Thanks for the fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU

Re: Running bash using su -c causes 100% cpu usage on one core

On 1/4/16 1:03 PM, Marcus Wichelmannn wrote: > Afaik it's a symlink to /usr/bin/mono. > > I solved my issue by replacing the line in /etc/rc.local by: > > su cubie -c "screen -S Haussteuerung -d -m > /home/cubie/Haussteuerung/Haussteuerung/run.sh" > > But this is no fix of this bug for sure.

Re: Running bash using su -c causes 100% cpu usage on one core

On 1/3/16 6:27 PM, Marcus Wichelmann wrote: > Hi, > > Im not sure if this is a regression because I already found another bug > report with the same symptoms from 2007, but when adding this line to the > /etc/rc.local the cpu usage of one of the two cores raises to 100%: >

Re: Running bash using su -c causes 100% cpu usage on one core

etc/rc.local + alias ls=ls --color + echo 0 + exit 0 + su cubie -c (cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh) -s /bin/sh Output from htop (the first process has a cpu usage of 100%): PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.

Re: Running bash using su -c causes 100% cpu usage on one core

On 1/4/16 9:01 AM, Marcus Wichelmannn wrote: utput from htop (the first process has a cpu usage of 100%): > >> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command >> 2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.44 /usr/bin/cli >> ./Haussteuerung What is /usr/bin/c

Re: Running bash using su -c causes 100% cpu usage on one core

Am Mo, 4. Jan, 2016 um 3:32 schrieb Chet Ramey <chet.ra...@case.edu>: On 1/4/16 9:01 AM, Marcus Wichelmannn wrote: utput from htop (the first process has a cpu usage of 100%): PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.4

Re: Running bash using su -c causes 100% cpu usage on one core

On Mon, Jan 04, 2016 at 07:03:39PM +0100, Marcus Wichelmannn wrote: > Am Mo, 4. Jan, 2016 um 3:32 schrieb Chet Ramey : > >What is /usr/bin/cli? It's the program that is using the CPU. > > Afaik it's a symlink to /usr/bin/mono. > > I solved my issue by replacing the line in

Re: Running bash using su -c causes 100% cpu usage on one core

It's impossible to tell with the amount of info you provided. That's why there's a 'bashbug' script alongside bash to generate a useful bug report template. Provide: - bash version: bash --version - OS name and version: uname -a - The contents of the run.sh file - If possible also the su version

Running bash using su -c causes 100% cpu usage on one core

Hi, Im not sure if this is a regression because I already found another bug report with the same symptoms from 2007, but when adding this line to the /etc/rc.local the cpu usage of one of the two cores raises to 100%: su cubie -c "(cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh)&quo

Re: Usage of __P vs PARAMS in histfile.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/8/15 8:47 PM, Mike Frysinger wrote: do you still support such old systems that require this pre-ANSI prototypes ? pretty much all other GNU projects have dropped support for them. I will drop support for them, too. - -- ``The lyf so

Re: Usage of __P vs PARAMS in histfile.c

On 08 Apr 2015 14:13, Chet Ramey wrote: On 4/8/15 11:25 AM, Evan Gates wrote: I tried compiling bash with musl-gcc and failed due to the __P macros in histfile.c While digging around it appears that __P is defined in stdc.h, but histfile.c indirectly includes rlstdc.h istead. rlstdc.h

Where is the usage for x in a b c; { echo $x; } documented in bash man page?

Hi, The following code works in bash. for x in a b c; { echo $x; } But I only find the following in bash man page. Does anybody know where the above usage is documented? Thanks. for name [ [ in [ word ... ] ] ; ] do list ; done -- Regards, Peng

Re: Where is the usage for x in a b c; { echo $x; } documented in bash man page?

On Sat, Mar 07, 2015 at 05:10:51PM -0600, Peng Yu wrote: Hi, The following code works in bash. for x in a b c; { echo $x; } But I only find the following in bash man page. Does anybody know where the above usage is documented? Thanks. for name [ [ in [ word ... ] ] ; ] do list ; done

fix ctype usage bugs in readline

such suspicious usage, but so far no one has listened to me): vi_mode.c: In function 'rl_vifword': vi_mode.c:557:7: error: array subscript has type 'char' [-Werror=char-subscripts] if (_rl_isindent (rl_line_buffer[rl_point])) ^ and many other similar warnings. The following patch silences

Re: Debugging memory usage

I took a look and saw the bash process consuming as much as 3+ GB of memory. I'm not doing anything where I'd expect to be consuming that much memory. As a workaround, try using ulimit -v to restrict the virtual memory space of the shell itself. (For invoking some child processes, it may

Re: Debugging memory usage

On Mon, Jun 24, 2013 at 11:45:19AM -0700, John Reiser wrote: I took a look and saw the bash process consuming as much as 3+ GB of memory. I'm not doing anything where I'd expect to be consuming that much memory. As a workaround, try using ulimit -v to restrict the virtual memory space

Debugging memory usage

I have a fairly involved script that handles some build management tasks, which can run for as long as several hours. I've recently seen it fail primarily due to failures to fork due to insufficient memory. I took a look and saw the bash process consuming as much as 3+ GB of memory. I'm not

Missing options in ulimit usage string

the -b option in the usage string and is missing the -T option in both the usage string and the Options section of the help description. doc/FAQ in the bash 4.2 source tarball says both options were added in bash 4.0. Repeat-By: Run `help ulimit` and note that -b is listed in the Options section

Re: Coproc usage ... not understanding

On Tue, Aug 09, 2011 at 05:47:09PM -0700, Linda Walsh wrote: Bob Proulx wrote: This may be a good point to mention this reference: http://www.pixelbeat.org/programming/stdio_buffering/ Does it only work with gnu programs? I.e. how would they know to not buffer Sounds like

Re: Coproc usage ... not understanding

Greg Wooledge wrote: Linda Walsh wrote: Bob Proulx wrote: This may be a good point to mention this reference: http://www.pixelbeat.org/programming/stdio_buffering/ Does it only work with gnu programs? I.e. how would they know to not buffer Sounds like the GNU

Re: Coproc usage ... not understanding

On Wed, Aug 10, 2011 at 10:07:20AM -0600, Bob Proulx wrote: The unbuffer expect script sets up a tty around the called program so that instead of a pipe the program detects a tty. The stdbuf utility works by setting up an LD_PRELOAD library libstdbuf.so that replaces the libc calls and

Re: Coproc usage ... not understanding

On 8/3/11 4:11 PM, Linda Walsh wrote: I've searched for coproc usage examples on the web, but there aren't many, and the few I found, while working for their test case, didn't fully replicate my setup, so it didn't work. Ideas? What am I doing wrong? You're probably running

Re: Coproc usage ... not understanding

Chet Ramey wrote: What am I doing wrong? You're probably running into grep (and sort, and sed) buffering its output. I haven't been able to figure out a way past that. Chet --- I did think of that...but I thought when the foreground process closes 'input', then all of the chained

Re: Coproc usage ... not understanding

Linda Walsh wrote: I did think of that...but I thought when the foreground process closes 'input', then all of the chained utils should see 'eof', and should then flush their output...at least that was my belief in how they should be working...(sigh)... --- Um...that got me to

Re: Coproc usage ... not understanding

Chet Ramey wrote: Linda Walsh wrote: Ideas? You're probably running into grep (and sort, and sed) buffering its output. I haven't been able to figure out a way past that. This may be a good point to mention this reference: http://www.pixelbeat.org/programming/stdio_buffering/ And the

Re: Coproc usage ... not understanding

Bob Proulx wrote: Chet Ramey wrote: Linda Walsh wrote: Ideas? You're probably running into grep (and sort, and sed) buffering its output. I haven't been able to figure out a way past that. This may be a good point to mention this reference:

Re: Coproc usage ... not understanding

On 8/9/11 8:19 PM, Linda Walsh wrote: Linda Walsh wrote: I did think of that...but I thought when the foreground process closes 'input', then all of the chained utils should see 'eof', and should then flush their output...at least that was my belief in how they should be

Coproc usage ... not understanding

at least 1 line of coproc's output to stdin. I've searched for coproc usage examples on the web, but there aren't many, and the few I found, while working for their test case, didn't fully replicate my setup, so it didn't work. Ideas? What am I doing wrong? Thanks, -linda (GNU bash

Re: Coproc usage ... not understanding

awk would be much better suited for this task. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.

Re: Coproc usage ... not understanding

I could do the whole thing in perl as well. Part of my reluctance to do that, is I wanted to learn why coproc wasn't working, and how to make it work. If I only use 'old skills', how will I learn anything new? Andreas Schwab wrote: awk would be much better suited for this task. Andreas.

Re: bash: Correct usage of F_SETFD

Eric Blake [ebl...@redhat.com] wrote: | | So if bash is the one creating its file descriptors, there's no need to | use R/M/W since it knows what the state of them are. | | No, bash cannot reasonably know what the implementation's default bit | state is, and blindly setting all other bits to

Re: bash: Correct usage of F_SETFD

)) | | Is that really the correct/intended usage of F_SETFD ? | | F_SETFDSet the close-on-exec flag associated with fildes to | the low order bit of arg (0 or 1 as above). Is that the POSIX definition ? Following man page does not limit F_SETFD to FD_CLOEXEC

bash: Correct usage of F_SETFD

include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? If kernel ever adds a new flag to the fd, this would end up clearing the other new flag right ? Shouldn't bash use F_GETFD

Re: bash: Correct usage of F_SETFD

include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? F_SETFDSet the close-on-exec flag associated with fildes to the low order bit

Re: bash: Correct usage of F_SETFD

On 11/22/2010 03:16 PM, Chet Ramey wrote: include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? F_SETFDSet the close-on-exec flag associated with fildes

Re: Bash high memory usage in simple for loop?

On 9/26/10 11:20 PM, Thomas Guyot-Sionnest wrote: For instance I have 68M of small numbers (1..256) separated by newlines and that makes bash grow over 1.6G, even when ann it does inside the loop is calling true. The only way I can free up the memory is to leave the shell. You can test

The usage of [[ (not with if)

Hello All, I have the following script and output. The man page says Return a status of 0 or 1 depending on the evaluation of the conditional expression expression. Therefore, I thought that the two printf statements should print 1 and 0 respectively. But both of them print 0. I'm wondering

Re: The usage of [[ (not with if)

On Wednesday 04 Aug 2010 16:03:25 Peng Yu wrote: I have the following script and output. The man page says Return a status of 0 or 1 depending on the evaluation of the conditional expression expression. Therefore, I thought that the two printf statements should print 1 and 0 respectively.

Re: The usage of [[ (not with if)

Peng Yu wrote: I have the following script and output. The man page says Return a status of 0 or 1 depending on the evaluation of the conditional expression expression. Therefore, I thought that the two printf statements should print 1 and 0 respectively. But both of them print 0. I'm

  1   2   >