globstar shell option could be enabled by default in future EAPIs.
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.
This bug should remain open and wait for an EAPI, which requires newer bash.
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.
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)
(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 ;).
(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?
(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.]
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.
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.
Closing following the other bug, we've decided for keeping the default bash behavior to avoid confusion. Enabling globstar is simple enough if necessary.
