Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15507 > unrolled thread

Re: Command grouping

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Command grouping Mischa Baars <mjbaars1977.bug-bash@cyberfiber.eu> - 2019-10-14 12:37 +0200

#15507 — Re: Command grouping

On Sun, 2019-10-13 at 10:54 +0100, kfm@plushkava.net wrote:
> On Sun, 13 Oct 2019 10:09:26 +0200
> Mischa Baars <mjbaars1977.bug-bash@cyberfiber.eu> 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.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web