Gentoo Archives: gentoo-dev

From: Roy Marples <uberlord@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: sh versionator.eclass
Date: Tue, 02 Oct 2007 10:42:30
Message-Id: 1191320664.6284.49.camel@uberlaptop.marples.name
In Reply to: Re: [gentoo-dev] RFC: sh versionator.eclass by Mike Frysinger
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

Replies

Subject Author
Re: [gentoo-dev] RFC: sh versionator.eclass Mike Frysinger <vapier@g.o>