On Tuesday 02 October 2007, Roy Marples wrote: > On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote: > > > > 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.
i am convinced by superior standards and by good things. forcing the standard
from bash to POSIX is neither of these. i dont see that as a flaw in my
logic.
> > 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.
having the option leads to better code. sometimes positional parameter usage
is a better idea, sometimes it is not.
> 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.
positional parameters provide a workaround for *1* array. what if you need
two ? three ? well damn, you're pickled in the pooper i think.
> 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.
case statements can be used in place of *some* statements, but not nearly all
and certainly does not provide the extended logic combining capabilities.
need to do boolean logic ? say hello to convoluted nested case statements!
> 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.
i dont buy either of these as "solutions" but "workarounds". "workarounds"
get punted for "solutions".
> > > 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.
yes it does. here's the scenario: use 1 find statement that is clear and
concise (but requires a GNU extension) or chain 1 find statement into
multiple other programs and combine it with shell code. you get the same
result, but the former is a ton easier to maintain. bogus scenario you say ?
i just dealt with it.
-mike
signature.asc
Description: This is a digitally signed message part.
