From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Icg9L-0002z3-Uj for garchives@archives.gentoo.org; Tue, 02 Oct 2007 11:42:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l92BWMR4003884; Tue, 2 Oct 2007 11:32:22 GMT Received: from mail.marples.name (rsm.demon.co.uk [80.177.111.50]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l92BSq5F031115 for ; Tue, 2 Oct 2007 11:28:52 GMT Received: from [10.73.1.31] (uberlaptop.marples.name [10.73.1.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTP id EAFFF190038 for ; Tue, 2 Oct 2007 12:28:51 +0100 (BST) Subject: Re: [gentoo-dev] RFC: sh versionator.eclass From: Roy Marples To: gentoo-dev@lists.gentoo.org In-Reply-To: <200710020657.25080.vapier@gentoo.org> References: <200710012259.40589.uberlord@gentoo.org> <200710020539.33189.vapier@gentoo.org> <1191320664.6284.49.camel@uberlaptop.marples.name> <200710020657.25080.vapier@gentoo.org> Content-Type: text/plain Organization: Gentoo Date: Tue, 02 Oct 2007 12:28:30 +0100 Message-Id: <1191324510.6284.107.camel@uberlaptop.marples.name> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit X-Archives-Salt: 0ca2bc75-6abb-43c6-be40-6f99a7094746 X-Archives-Hash: fe594732a826bd62b0452fae6f810a4a 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 -- gentoo-dev@gentoo.org mailing list