On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot <[email protected]> wrote:
> I concur that speaking for myself, I don't understand the issue. And
> it looks like many others don't either. So if anyone wants to promote
> this GLEP, their job is clear: make people understand what the issue
> is here, and convince them it is actually an issue. (Examples,
> scenarios usually work well, indeed a lot better than calling people
> names.)
We need a mechanism to be able to use newer bash-features in ebuilds.
Preferably one that doesn't go "Wait a couple of years, hope
everyone did X then Just Do it." We want one that goes like "Get a new
EAPI approved with new minimum bash-version attached, start using cool
stuff like ( Bash-4.0 ):
shopt -s globstar
for i in /usr/share/man/**/*remote*
do
stuff
done
Built-in find in bash, how do you like them bananas? :-)
find equivalent would be, if you wanted the same level of space-safety:
while read -r line
do
stuff
done < <(find /usr/share/man -name '*remote*')
Personally, I like the first version better. It would be cool if we
could start using it sooner. GLEP-55 provides the "clean" solution, by
just making the file name indicate what's inside. No need to parse, no
nothing. Portage is currently testing a "first line with EAPI=
determines EAPI" method. That's slightly less clean, but has the added
benefit of not breaking anything that relies on .ebuild extension for
ebuilds and I think it's not an unreasonable limitation on ebuilds to
require EAPI= to be parseable by !bash.
/loki_val
