bug-bash
[Top][All Lists]
Advanced

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

Re: Command grouping


From: Mischa Baars
Subject: Re: Command grouping
Date: Mon, 14 Oct 2019 12:37:34 +0200
User-agent: Evolution 3.32.4 (3.32.4-1.fc30)

On Sun, 2019-10-13 at 10:54 +0100, address@hidden wrote:
> On Sun, 13 Oct 2019 10:09:26 +0200
> Mischa Baars <address@hidden> wrote:
> 
> > On Sat, 2019-10-12 at 10:42 -0400, Chet Ramey wrote:
> > > On 10/12/19 9:02 AM, Mischa Baars wrote:
> > > > Hi,
> > > > 
> > > > Perhaps to better have a look at this mail, than the previous mail.
> > > > 
> > > > In trying to group commands, in this case compiler commands, I found 
> > > > some peculiarities while trying different combinations of the 'Internal 
> > > > Field
> > > > Separator'
> > > > and the 'Parameter Expansion' operator ${parameter@P}.
> > > 
> > > I haven't looked at this in any depth, but you should realize that running
> > > 
> > > declare IFS=$(printf ' \t\n')
> > > 
> > > will result in IFS being set to space and tab, since command substitution
> > > removes the trailing newline. Maybe that will make a difference.
> > > 
> > 
> > Hi Chet,
> > 
> > The bash manual page tells us that is the default value, nothing special.
> > 
> > I was trying to remove the whitespace, such that whitespaces are allowed in 
> > project directory names, as was considered the default scenario as far as I
> > know.
> 
> You are not removing the whitespace values from IFS. Instead, you are 
> re-asserting the default value of IFS, only with \n missing (for the reason 
> that Chet
> describes). Given that the output of your find command is newline-delimited, 
> doing so will not end well. Writing IFS=$'\n' may function as you expected.
> However, this is an intrinsically broken approach to begin with. See 
> https://mywiki.wooledge.org/DontReadLinesWithFor.
> 
> Instead, consider any of the following options:-
> 
>   * find -exec or -execdir
>   * a for loop that iterates over a glob
>   * a while/read loop that consumes find's output (using -print0, ideally)
> 
> Your problems are compounded by failing to quote the expansion of i in the 
> course of invoking gcc (lines 4-5), and by the flawed attempt at a workaround
> (lines 2 and 6-7). See https://mywiki.wooledge.org/BashFAQ/050. Not only 
> that, but the *.c argument conveyed to find should be quoted, so as to inhibit
> pathname expansion.
> 
> Here is an example of how one might use for:-
> 
> shopt -s globstar
> for i in ./pace/**/*.c; do
>   gcc -o "${i%.c}" "$i"
> done
> 

Hi Kerin,

I believe you're missing the point. You were probably distracted by me 
brabbling about whitespaces.

Again. When scripting, commands often do not fit on one line. To overcome this 
problem, let's try to separate the commands from the loops:

--- emphasis on separation ---

shopt -s globstar; export E0="\${i}"; for i in ./pace/**/*.c; do ls ${E0@P}; 
done;              # functions as supposed to
shopt -s globstar; export E0="ls \${i}"; for i in ./pace/**/*.c; do ${E0@P}; 
done;              # functions as supposed to

--- emphasis on pathname expansion ---

shopt -s globstar; export E0="\${i}"; for i in ./pace/**/*.c; do ls "${E0@P}"; 
done;            # functions as supposed to
shopt -s globstar; export E0="ls \${i}"; for i in ./pace/**/*.c; do "${E0@P}"; 
done;            # does not function as supposed to

Aliases are not defined in makefiles, and I remember there to be something 
uncomfortable with functions in the loop too, I would have to look that up. So 
we'll
have to do with variables being used to define functions.

Regards,
Mischa.




reply via email to

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