[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-threaded compiling
From: |
alex xmb sw ratchev |
Subject: |
Re: multi-threaded compiling |
Date: |
Tue, 12 Mar 2024 09:30:09 +0100 |
On Tue, Mar 12, 2024, 09:26 Mischa Baars <mjbaars1977.backup@gmail.com>
wrote:
> On Mon, Mar 11, 2024 at 10:26 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> > On 3/11/24 3:44 PM, Mischa Baars wrote:
> > > On Mon, 11 Mar 2024, 20:20 Chet Ramey, <chet.ramey@case.edu
> > > <mailto:chet.ramey@case.edu>> 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 and when the shell notifies the user about job
> > completion,
> > > most likely, two of the relevant things that differ between
> > interactive
> > > and non-interactive shells.
> > >
> > >
> > > Wasn't expecting any better answer, but thanks anyway.
> >
> > OK, here's the longer answer. When the shell is interactive, and job
> > control is enabled, the shell prints job completion notifications to
> > stdout at command boundaries. Once the shell notifies the user of a
> > job's completion, it is no longer `new' (or the `next', whichever
> > mnemonic you prefer), and `wait -n' will not return it.
> >
> > So if you include the complete output of an interactive shell executing
> > the above list (with the obvious corrections already discussed), you'll
> > get a series of
> >
> > 32 messages about job creation
> > 32 notifications of job exits, with exit status (they exit immediately,
> > after all)
> > 32 error messages because the user has already been notified of the
> > job's completion and the shell has reaped it (so it is no longer the
> > `next' job to exit)
> >
> > When the shell is not interactive, it only prints job notifications to
> > stdout when the job is terminated by a signal, so the jobs are available
> > to `wait -n'.
> >
> > There was quite a long discussion about this aspect of `wait -n' behavior
> > a couple of months ago, starting at
> >
> > https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00104.html
> >
> >
> > > And the script from directory 'two'? How do I pass this string through
> > the
> > > CFLAGS variable to the compiler? What am I doing wrong in #3 of the
> > script?
> >
> > You're not taking word splitting into account. It seems like you want
> > selective word splitting -- for the embedded double quotes in the various
> > elements of CFLAGS to have some semantic meaning and somehow inhibit
> > word splitting. Quotes are special to the parser, not when they are in
> > the results of word expansion. If you want the parser to evaluate the
> > results of word expansion, you're going to have to run it through the
> > parser again, using something like `eval'.
> >
> > It's clearer if you replace `gcc' in your command with
> >
> > printf '<%s> '
> >
> > and `./main' with `echo'.
> >
> > Yes. Now I see a difference in all the different lines. I wasn't familiar
> with this printf construct, but the results are clear:
>
> Using make:
>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
>
> Using ./make.sh:
>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__=one and two>
>
> and either for unquoted variable in #3
>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__="one><and><two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=0><-D__STRING__="one><and><two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__="one><and><two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=1><-D__STRING__="one><and><two">
>
> or for double quoted variable in #3
>
> <gcc><-o><main><main.c><-D__STRINGIZED__=0 -D__STRING__="one and two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=0 -D__STRING__="one and two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=1 -D__STRING__="one and two">
> <gcc><-o><main><main.c><-D__STRINGIZED__=1 -D__STRING__="one and two">
>
> So... how do I fix it?
>
if u need to expand quotes , use any builtin
like
declare -a "arr=( $var_to_expand )" and use arr[@]
> --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> > ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRU chet@case.edu
> http://tiswww.cwru.edu/~chet/
> >
> >
>
- Re: multi-threaded compiling, (continued)
- Re: multi-threaded compiling, alex xmb sw ratchev, 2024/03/11
- Re: multi-threaded compiling, Mischa Baars, 2024/03/11
- Re: multi-threaded compiling, alex xmb sw ratchev, 2024/03/11
- Re: multi-threaded compiling, alex xmb sw ratchev, 2024/03/11
- Re: multi-threaded compiling, Mischa Baars, 2024/03/11
- Re: multi-threaded compiling, Mischa Baars, 2024/03/11
- Re: multi-threaded compiling, Chet Ramey, 2024/03/11
- Re: multi-threaded compiling, Mischa Baars, 2024/03/11
- Re: multi-threaded compiling, Chet Ramey, 2024/03/11
- Re: multi-threaded compiling, Mischa Baars, 2024/03/12
- Re: multi-threaded compiling,
alex xmb sw ratchev <=
- Re: multi-threaded compiling, Chet Ramey, 2024/03/12
- Re: multi-threaded compiling, Robert Elz, 2024/03/12
- Re: multi-threaded compiling, Mischa Baars, 2024/03/12
- Re: multi-threaded compiling, Robert Elz, 2024/03/12
- Re: multi-threaded compiling, Greg Wooledge, 2024/03/12
- Re: multi-threaded compiling, Mischa Baars, 2024/03/12
- Re: multi-threaded compiling, Chet Ramey, 2024/03/12
- Re: multi-threaded compiling, Mischa Baars, 2024/03/12
- Re: multi-threaded compiling, Martin D Kealey, 2024/03/12
- Re: multi-threaded compiling, Mischa Baars, 2024/03/13