| 1 |
On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote: |
| 2 |
> i am convinced by superior standards and by good things. forcing the standard |
| 3 |
> from bash to POSIX is neither of these. i dont see that as a flaw in my |
| 4 |
> logic. |
| 5 |
|
| 6 |
Forcing? I'm not asking for anything to be forced, I'm asking for it to |
| 7 |
be allowed. |
| 8 |
|
| 9 |
By the same token, I don't force anyone to write a sh init script and I |
| 10 |
allow bash init scripts in baselayout. |
| 11 |
|
| 12 |
> positional parameters provide a workaround for *1* array. what if you need |
| 13 |
> two ? three ? well damn, you're pickled in the pooper i think. |
| 14 |
|
| 15 |
Not exactly true, you can use multi dimensional arrays through eval |
| 16 |
usage. Nasty I know, but I think the same thing about arrays like so |
| 17 |
anyway. |
| 18 |
|
| 19 |
> > Pattern matching can be done just as well with case. Infact, tend to use |
| 20 |
> > [[ == ]] a lot when pattern matching when a case statement would be more |
| 21 |
> > efficient and use less code. Of course when you're just interested in |
| 22 |
> > matching one one thing in a code block then it uses more code, but that |
| 23 |
> > is probably outside the norm. |
| 24 |
> |
| 25 |
> case statements can be used in place of *some* statements, but not nearly all |
| 26 |
> and certainly does not provide the extended logic combining capabilities. |
| 27 |
> need to do boolean logic ? say hello to convoluted nested case statements! |
| 28 |
|
| 29 |
Then variables should be used to make the code readable. |
| 30 |
|
| 31 |
> > String replacements. This is the real bug bear isn't it? sh has no easy |
| 32 |
> > answer to this, but that doesn't mean that we can't use it. We use many |
| 33 |
> > eclass specific functions, so why not have another? |
| 34 |
> > foo=${haystack//needle/thread} |
| 35 |
> > foo="$(ereplace "${haystack}" "${needle}" "${thread}")" |
| 36 |
> > |
| 37 |
> > I already have sh code that handles that as we can't call external bins |
| 38 |
> > in global scope for ebuilds. But for everything else there's sed. |
| 39 |
> |
| 40 |
> i dont buy either of these as "solutions" but "workarounds". "workarounds" |
| 41 |
> get punted for "solutions". |
| 42 |
|
| 43 |
By the same token, epatch is a "workaround" to apply non exact patches. |
| 44 |
The correct "solution" is to craft an exact patch. So we should punt |
| 45 |
epatch too? |
| 46 |
|
| 47 |
> > > > This same rationale applies to scriptlets outside portage tree use, |
| 48 |
> > > > such as revdep-rebuild [1]. It's more of a bashlet, but I've also |
| 49 |
> > > > demonstrated that there was no reason to force bash there. |
| 50 |
> > > |
| 51 |
> > > not really ... there's a reason the environment dictated inside of the |
| 52 |
> > > package manager requires GNU stuff ... the extensions provided make life |
| 53 |
> > > easy. all this conversion from trivial GNU extensions to limited POSIX |
| 54 |
> > > interfaces is a pita (as can trivially be seen with find and xargs). as |
| 55 |
> > > for "no reason", just because it can be done differently doesnt mean it |
| 56 |
> > > should. |
| 57 |
> > |
| 58 |
> > Using the same argument, just because there is a GNU extension does not |
| 59 |
> > mean it should be used. |
| 60 |
> |
| 61 |
> yes it does. here's the scenario: use 1 find statement that is clear and |
| 62 |
> concise (but requires a GNU extension) or chain 1 find statement into |
| 63 |
> multiple other programs and combine it with shell code. you get the same |
| 64 |
> result, but the former is a ton easier to maintain. bogus scenario you say ? |
| 65 |
> i just dealt with it. |
| 66 |
|
| 67 |
Let me guess - openssl? |
| 68 |
|
| 69 |
Thanks |
| 70 |
|
| 71 |
Roy |
| 72 |
|
| 73 |
-- |
| 74 |
gentoo-dev@g.o mailing list |
Archives