On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> 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.
Forcing? I'm not asking for anything to be forced, I'm asking for it to
be allowed.
By the same token, I don't force anyone to write a sh init script and I
allow bash init scripts in baselayout.
> positional parameters provide a workaround for *1* array. what if you need
> two ? three ? well damn, you're pickled in the pooper i think.
Not exactly true, you can use multi dimensional arrays through eval
usage. Nasty I know, but I think the same thing about arrays like so
anyway.
> > 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!
Then variables should be used to make the code readable.
> > 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".
By the same token, epatch is a "workaround" to apply non exact patches.
The correct "solution" is to craft an exact patch. So we should punt
epatch too?
> > > > 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.
Let me guess - openssl?
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
