bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-threaded compiling


From: Chet Ramey
Subject: Re: multi-threaded compiling
Date: Mon, 11 Mar 2024 17:25:57 -0400
User-agent: Mozilla Thunderbird

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'.


--
``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/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]