On 3/11/24 3:44 PM, Mischa Baars wrote:
On Mon, 11 Mar 2024, 20:20 Chet Ramey, <chet.ra...@case.edu <mailto:chet.ra...@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 c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature