On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote:
> > The bonus is that it works on shells other than bash.
>
> which is irrelevant here
I think otherwise.
>
> > > I personally like consistency. So if we use bash in ebuilds, then I'd
> > > like to use bash in eclasses too. I'm interested in your motivation to
> > > make this eclass "pure sh", whatever that may mean.
> >
> > I like consistency too, and I'll be pushing for using sh instead of
> > forcing bash.
>
> pushing a new standard by slowly converting the tree is not the way to go.
That's why I'm here talking, trying to convince people. Some people like
yourself will never be convinced though.
> POSIX lacks useful bash extensions that are used heavily ... arrays, string
> replacements, pattern matching with [[ == ]] to name some. here's
> your "technical" reason for using the bash standard over POSIX: it's
> superior.
POSIX has positional parameters, which provide array like functionality.
I would argue that this is better as you cannot pass an array to a
function - you have to pass it as positional parameters.
I agree that the bash array is superior as you can grab the index of
items >=10 easily and walk it backwards, but I've yet to see a case
where it cannot be done otherwise.
Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.
String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo="$(ereplace "${haystack}" "${needle}" "${thread}")"
I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.
> > This same rationale applies to scriptlets outside portage tree use, such
> > as revdep-rebuild [1]. It's more of a bashlet, but I've also
> > demonstrated that there was no reason to force bash there.
>
> not really ... there's a reason the environment dictated inside of the
> package
> manager requires GNU stuff ... the extensions provided make life easy. all
> this conversion from trivial GNU extensions to limited POSIX interfaces is a
> pita (as can trivially be seen with find and xargs). as for "no reason",
> just because it can be done differently doesnt mean it should.
Using the same argument, just because there is a GNU extension does not
mean it should be used.
Roy
--
[EMAIL PROTECTED] mailing list
