Bug 414811 – [Future EAPI] globstar shell option enabled by default

• Product: Gentoo Hosted Projects
• Status: RESOLVED WONTFIX

[Description Arfrever Frehtes Taifersar Arahesis 2012-05-06 02:45:20 UTC]

globstar shell option could be enabled by default in future EAPIs.

[Comment 1 SpanKY 2012-05-06 05:23:33 UTC]

globstar is new to bash-4.0.  thus you first have to start requiring bash-4.0, and any ebuild using globstar today is not valid.

[Comment 2 Arfrever Frehtes Taifersar Arahesis 2012-05-06 13:46:29 UTC]

This bug should remain open and wait for an EAPI, which requires newer bash.

[Comment 3 Michał Górny 2013-08-30 10:27:40 UTC]

What is the rationale/use case for this? Not that I'm disagreeing but the [Future EAPI] bugs should have at least some short explanation.

[Comment 4 Arfrever Frehtes Taifersar Arahesis 2013-08-30 13:38:59 UTC]

Ebuilds will be able to use ** instead of calling `find`.

Example of code with **:
  sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i **/Makefile

Example of code with `find`:
  # Some Makefiles are in directories with spaces.
  while read -d $'\0' -r file; do
    sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i "${file}"
  done < <(find -name Makefile -print0)

[Comment 5 Michał Górny 2013-08-30 14:54:18 UTC]

(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> Ebuilds will be able to use ** instead of calling `find`.
> 
> Example of code with **:
>   sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i **/Makefile
> 
> Example of code with `find`:
>   # Some Makefiles are in directories with spaces.
>   while read -d $'\0' -r file; do
>     sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i "${file}"
>   done < <(find -name Makefile -print0)

  find -name Makefile -exec \
    sed -i -e "s/^CC = gcc/CC = $(tc-getCC)/" {} +

And to be honest, I doubt many developers will actually use that. It's simply not intuitive ;).

[Comment 6 Ulrich Müller 2013-08-30 18:31:18 UTC]

(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> Ebuilds will be able to use ** instead of calling `find`.

Do we really want this?

[Comment 7 Steve L 2013-09-07 18:44:17 UTC]

(In reply to Michał Górny from comment #5)
> > Example of code with **:
> >   sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i **/Makefile
> > 
> > Example of code with `find`:
> >   # Some Makefiles are in directories with spaces.
> >   while read -d $'\0' -r file; do
> >     sed -e "s/^CC = gcc/CC = $(tc-getCC)/" -i "${file}"
> >   done < <(find -name Makefile -print0)
> 
>   find -name Makefile -exec \
>     sed -i -e "s/^CC = gcc/CC = $(tc-getCC)/" {} +
>
If you're going to set an example, then at least use a more correct regex:
.. sed -i "s@^[[:space:]]*CC[[:space:]]*=.*@CC = $(tc-getCC)@" {} +

(assuming '/' is ok as a separator there feels a bit suspect given that cross-compile situations might be using an absolute path, but feel free to change @ to whatever's best.)
> And to be honest, I doubt many developers will actually use that. It's
> simply not intuitive ;).

What's not intuitive; a glob? It's far more intuitive than use of find.

(In reply to Ulrich Müller from comment #6)
> (In reply to Arfrever Frehtes Taifersar Arahesis from comment #4)
> > Ebuilds will be able to use ** instead of calling `find`.
> 
> Do we really want this?

IMO we do, assuming we are requiring a stable Bash-4. Once that is in-place, it makes sense to stipulate that globstar is enabled, just like it made sense to specify extglob; so long as it does not change the course of normal operation, ie where code not using those features is unaffected. That is normally the case with new bash features, since they deliberately choose an altered syntax that is unlikely to appear in normal script. ** is a redundancy, and normally a typo.

It's proven useful, which is why zsh has it, admittedly with more functionality via glob qualifiers. It makes shell functions more useful, and you can call those with globbed params intermingled with literals or arrays. As a contrived example, imagine we had to use POSIX-compliant ed instead of sed -i:

# change_CC **/Makefile
change_CC(){
   local f cc e=0
   cc=$(tc-getCC) || die "$FUNCNAME: tc-getCC: ret $?"
   cc=${cc//\//\\/}
   for f; do
      [[ -f $f ]] && grep -q '/^[[:space:]]*CC[[:space:]]*=/' "$f" || continue
      printf '%s\n' H 'g/^[[:space:]]*CC[[:space:]]*=.*/s//CC = '"$cc/" w | ed -s "$f" && continue
      ewarn "blah '$f'"
      let e++
   done
   ((e))
}

It could be any other command, or more cogently eclass function, that is not amenable to calling via find: full shell flexibility - eg: you can set variables scoped to the calling function - (and efficiency) is retained, using a syntax that is becoming a de-facto standard (tho ebuilds are bash-specific) since it fits with standard globbing, which is _central_ to all shell.

Other features like associative arrays are, like regexen were with 3.x, implicit in the version requirement.

[I am aware the above can be done with find, if you know what you're doing, but not pleasantly, and certainly nowhere near as intuitively for usage. It's just an example: eclass functions are more relevant in the context of find.]

[Comment 8 Ulrich Müller 2013-09-07 23:15:53 UTC]

I'm not so sure if such extensive usage of globbing should be encouraged. For example, globbing may run into issues with the maximum length of an argument list, but find will just handle such situations fine.

[Comment 9 Michał Górny 2014-09-06 22:03:25 UTC]

Well, bash-4 is becoming a fact now, so I'm removing the 'distant' flag. I don't have a strong opinion on this though. As I see it, enabling it wouldn't really hurt, however I don't expect many developers to actually make use of that. OTOH it could make a few tasks simpler and more error-proof, like Arfrever points out.

A bit late for that but considering the time needed to implement runtime USE flags, this could be an EAPI 6 candidate. However, it should be discussed on the ml first.

[Comment 10 Michał Górny 2017-09-08 18:59:07 UTC]

Closing following the other bug, we've decided for keeping the default bash behavior to avoid confusion. Enabling globstar is simple enough if necessary.