1 |
On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote: |
2 |
> > The bonus is that it works on shells other than bash. |
3 |
> |
4 |
> which is irrelevant here |
5 |
|
6 |
I think otherwise. |
7 |
> |
8 |
> > > I personally like consistency. So if we use bash in ebuilds, then I'd |
9 |
> > > like to use bash in eclasses too. I'm interested in your motivation to |
10 |
> > > make this eclass "pure sh", whatever that may mean. |
11 |
> > |
12 |
> > I like consistency too, and I'll be pushing for using sh instead of |
13 |
> > forcing bash. |
14 |
> |
15 |
> pushing a new standard by slowly converting the tree is not the way to go. |
16 |
|
17 |
That's why I'm here talking, trying to convince people. Some people like |
18 |
yourself will never be convinced though. |
19 |
|
20 |
|
21 |
> POSIX lacks useful bash extensions that are used heavily ... arrays, string |
22 |
> replacements, pattern matching with [[ == ]] to name some. here's |
23 |
> your "technical" reason for using the bash standard over POSIX: it's |
24 |
> superior. |
25 |
|
26 |
POSIX has positional parameters, which provide array like functionality. |
27 |
I would argue that this is better as you cannot pass an array to a |
28 |
function - you have to pass it as positional parameters. |
29 |
I agree that the bash array is superior as you can grab the index of |
30 |
items >=10 easily and walk it backwards, but I've yet to see a case |
31 |
where it cannot be done otherwise. |
32 |
|
33 |
Pattern matching can be done just as well with case. Infact, tend to use |
34 |
[[ == ]] a lot when pattern matching when a case statement would be more |
35 |
efficient and use less code. Of course when you're just interested in |
36 |
matching one one thing in a code block then it uses more code, but that |
37 |
is probably outside the norm. |
38 |
|
39 |
String replacements. This is the real bug bear isn't it? sh has no easy |
40 |
answer to this, but that doesn't mean that we can't use it. We use many |
41 |
eclass specific functions, so why not have another? |
42 |
foo=${haystack//needle/thread} |
43 |
foo="$(ereplace "${haystack}" "${needle}" "${thread}")" |
44 |
|
45 |
I already have sh code that handles that as we can't call external bins |
46 |
in global scope for ebuilds. But for everything else there's sed. |
47 |
|
48 |
> > This same rationale applies to scriptlets outside portage tree use, such |
49 |
> > as revdep-rebuild [1]. It's more of a bashlet, but I've also |
50 |
> > demonstrated that there was no reason to force bash there. |
51 |
> |
52 |
> not really ... there's a reason the environment dictated inside of the package |
53 |
> manager requires GNU stuff ... the extensions provided make life easy. all |
54 |
> this conversion from trivial GNU extensions to limited POSIX interfaces is a |
55 |
> pita (as can trivially be seen with find and xargs). as for "no reason", |
56 |
> just because it can be done differently doesnt mean it should. |
57 |
|
58 |
Using the same argument, just because there is a GNU extension does not |
59 |
mean it should be used. |
60 |
|
61 |
Roy |
62 |
|
63 |
-- |
64 |
gentoo-dev@g.o mailing list |