On Tuesday 02 October 2007, Roy Marples wrote: > 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.
it already is allowed. bash is a superset of POSIX so anything that can be
done in POSIX can be done in bash. if you arent after changing the shell
standard inside of ebuilds to POSIX, then this discussion is moot. keep it
all bash so things remain consistent and we're done.
> > 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.
i'm fully aware of all the nested hacks that can be done with eval. that is
not an acceptable answer.
> > > 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.
so you'd advocate dropping one perfectly readable/understandable line of code
for multiple lines of variables/case statements ? that doesnt make sense.
> > > 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?
these things are not equivalent by any means. epatch provides a consistent
interface (both for ebuild writers and users) to apply patches where there
was none ... this gave us reliable behavior across the board in terms of how
patches were fed in, applied to the source, and errors were handled as well
as the output from the process (status messages and helpful debug information
from failures) ... the fact that epatch attempts with different -p# levels is
an extension to automate a step that is 99% of the time irrelevant to the
final result. these topics do not pertain to string replacements.
-mike
signature.asc
Description: This is a digitally signed message part.
