Re: multi-threaded compiling

2024-03-12 Thread Martin D Kealey
> On Mon, Mar 11, 2024 at 8:20 PM Chet Ramey wrote: > > On 3/11/24 2:50 PM, Mischa Baars wrote: > > > Which sort of brings us back to the original question I suppose. Who > does > > > that line of code function from a script and why does it fail from the > > > command line? > > > > Job control

Re: multi-threaded compiling

2024-03-12 Thread Paul Smith
On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > I'd still like to hear why you aren't simply using "make -j". > > That's because I don't want to define static compile and link targets > for every new project I start. The Makefile in question contains only > a few lines of code and some

Re: multi-threaded compiling

2024-03-12 Thread Chet Ramey
On 3/12/24 4:23 AM, Mischa Baars wrote: So... how do I fix it? If you want double quotes in a variable expansion to have some meaning to the parser, you need to run the expanded value through the parser, using something like `eval'. Or you figure out a different way to glue the arguments

Re: multi-threaded compiling

2024-03-12 Thread Chet Ramey
On 3/12/24 7:29 AM, Greg Wooledge wrote: hobbit:~$ bash -c 'set +m; for i in {0..3}; do sleep 1 & done; for i in {0..3}; do wait -n -p pid; e=$?; printf "pid %s status %s\n" "$pid" "$e"; done' pid 530407 status 0 pid 530410 status 0 pid status 127 pid status 127 Thanks for this example.

Bash printf should diagnose integer overflow

2024-03-12 Thread Paul Eggert
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux penguin.cs.ucla.edu 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 16:53:59 UTC 2024 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.3 Patch

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Tue, Mar 12, 2024 at 12:49 PM Greg Wooledge wrote: > On Tue, Mar 12, 2024 at 09:42:22AM +0100, Mischa Baars wrote: > > Here's the script and the Makefile using "printf '<%s>'": > > Sadly, your mail user agent chose to attach "Makefile" with content-type > application/octet-stream, which my

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Tue, Mar 12, 2024 at 12:30 PM Greg Wooledge wrote: > On Tue, Mar 12, 2024 at 02:15:38PM +0700, Robert Elz wrote: > > Date:Mon, 11 Mar 2024 17:25:57 -0400 > > From:Chet Ramey > > Message-ID: <322e10a6-3808-49be-aa9d-a1d367a90...@case.edu> > > > > | OK, here's

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Tue, Mar 12, 2024 at 12:19 PM Greg Wooledge wrote: > On Tue, Mar 12, 2024 at 10:33:36AM +0100, Mischa Baars wrote: > > bash -c 'set +m; seconds=1; for (( i=0;i<32;i++ )); do exit ${i} & done; > > sleep ${seconds}; for (( i=0;i<32;i++ )); do wait -p pid; e=${?}; echo > > "$(printf %3u ${i})

Re: multi-threaded compiling

2024-03-12 Thread alex xmb sw ratchev
On Tue, Mar 12, 2024, 12:49 Greg Wooledge wrote: > On Tue, Mar 12, 2024 at 09:42:22AM +0100, Mischa Baars wrote: > > Here's the script and the Makefile using "printf '<%s>'": > > Sadly, your mail user agent chose to attach "Makefile" with content-type > application/octet-stream, which my MUA

Re: multi-threaded compiling

2024-03-12 Thread Greg Wooledge
On Tue, Mar 12, 2024 at 09:42:22AM +0100, Mischa Baars wrote: > Here's the script and the Makefile using "printf '<%s>'": Sadly, your mail user agent chose to attach "Makefile" with content-type application/octet-stream, which my MUA (mutt) refuses to show inline, or to include in a reply as

Re: multi-threaded compiling

2024-03-12 Thread Greg Wooledge
On Tue, Mar 12, 2024 at 02:15:38PM +0700, Robert Elz wrote: > Date:Mon, 11 Mar 2024 17:25:57 -0400 > From:Chet Ramey > Message-ID: <322e10a6-3808-49be-aa9d-a1d367a90...@case.edu> > > | OK, here's the longer answer. When the shell is interactive, and job > |

Re: multi-threaded compiling

2024-03-12 Thread Greg Wooledge
On Tue, Mar 12, 2024 at 10:33:36AM +0100, Mischa Baars wrote: > bash -c 'set +m; seconds=1; for (( i=0;i<32;i++ )); do exit ${i} & done; > sleep ${seconds}; for (( i=0;i<32;i++ )); do wait -p pid; e=${?}; echo > "$(printf %3u ${i}) pid ${pid} exit ${e}"; done;' "wait -p pid" is not correct here.

Re: multi-threaded compiling

2024-03-12 Thread Robert Elz
Date:Tue, 12 Mar 2024 18:32:19 +1000 From:Martin D Kealey Message-ID: | You don't need '-n' when you specify a PID; the fix is simply to remove it. That's OK, when there is exactly one PID, but for a task like this, wait -n -p pid PID1 PID2 PID3 ...

Re: multi-threaded compiling

2024-03-12 Thread Robert Elz
| I think you forgot to look at the actual code in the Makefile here. No, I didn't forget, I never intended to look, unpacking attached tar.gz files is more effort than I'm willing to undertake. | Every '$' is written as a '$$', exactly as you say it should. OK, I guessed incorrectly ...

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
Got it!!! bash -c 'set +m; seconds=5; for (( i=0;i<32;i++ )); do exit ${i} & pid[${i}]=${!}; done; sleep ${seconds}; for (( i=0;i<32;i++ )); do wait ${pid[${i}]}; e=${?}; echo "$(printf %3u ${i}) pid ${pid[${i}]} exit ${e}"; done;' One problem solved :) The problem was exactly the -n, and had

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
Oh, sorry. Without the -n that is. bash -c 'set +m; seconds=1; for (( i=0;i<32;i++ )); do exit ${i} & done; sleep ${seconds}; for (( i=0;i<32;i++ )); do wait -p pid; e=${?}; echo "$(printf %3u ${i}) pid ${pid} exit ${e}"; done;' bash -c 'set -m; seconds=1; for (( i=0;i<32;i++ )); do exit ${i} &

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
Hi Chet, The only thing I can find about this behavior is the set +m / set -m option, which disables / enables the notifications, but has no effect otherwise. The line from the script won't execute from the command line with either option, neither enclosed with a 'bash -c' as in: set +m; bash

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
Here's the script and the Makefile using "printf '<%s>'": On Tue, Mar 12, 2024 at 9:32 AM Martin D Kealey wrote: > In section one, the problem is that "wait -n" does not do what you think > it does. (Lots of us think this behaviour is broken, and it may be fixed in > an upcoming version of

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Tue, Mar 12, 2024 at 9:32 AM Martin D Kealey wrote: > In section one, the problem is that "wait -n" does not do what you think > it does. (Lots of us think this behaviour is broken, and it may be fixed in > an upcoming version of Bash.) You don't need '-n' when you specify a PID; > the fix is

Re: multi-threaded compiling

2024-03-12 Thread Martin D Kealey
In section one, the problem is that "wait -n" does not do what you think it does. (Lots of us think this behaviour is broken, and it may be fixed in an upcoming version of Bash.) You don't need '-n' when you specify a PID; the fix is simply to remove it. In section two, the problem is that quote

Re: multi-threaded compiling

2024-03-12 Thread alex xmb sw ratchev
On Tue, Mar 12, 2024, 09:26 Mischa Baars wrote: > On Mon, Mar 11, 2024 at 10:26 PM Chet Ramey wrote: > > > On 3/11/24 3:44 PM, Mischa Baars wrote: > > > On Mon, 11 Mar 2024, 20:20 Chet Ramey, > > > wrote: > > > > > > On 3/11/24 2:50 PM, Mischa Baars wrote: > > >

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Mon, Mar 11, 2024 at 10:26 PM Chet Ramey wrote: > On 3/11/24 3:44 PM, Mischa Baars wrote: > > On Mon, 11 Mar 2024, 20:20 Chet Ramey, > > wrote: > > > > On 3/11/24 2:50 PM, Mischa Baars wrote: > > > Which sort of brings us back to the original question I

Re: multi-threaded compiling

2024-03-12 Thread Mischa Baars
On Tue, Mar 12, 2024 at 8:16 AM Robert Elz wrote: > This whole discussuon has been a total mess. > > First the original message didn't give nearly enough info. > That might have been in the attachment, but no-one should be > expecting people to do any needless work when you're asking > for

Re: multi-threaded compiling

2024-03-12 Thread Robert Elz
This whole discussuon has been a total mess. First the original message didn't give nearly enough info. That might have been in the attachment, but no-one should be expecting people to do any needless work when you're asking for (free) assistance - if you want help you need to make it as easy as