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 1Ii7FS-0002Xd-A6 for garchives@archives.gentoo.org; Wed, 17 Oct 2007 11:39:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l9HBSMhQ005548; Wed, 17 Oct 2007 11:28: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 l9HBQLL8002987 for ; Wed, 17 Oct 2007 11:26:21 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 2EBEE190038 for ; Wed, 17 Oct 2007 12:26:21 +0100 (BST) Subject: Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-php5/onphp: ChangeLog onphp-0.10.6.ebuild onphp-0.10.4.ebuild onphp-0.10.3.ebuild From: Roy Marples To: gentoo-dev@lists.gentoo.org In-Reply-To: References: <20071014211125.GB23990@supernova> <20071014235246.GA19544@phaenix.haell.com> <20071015022506.461cea64@eusebe> <20071016072812.GT23990@supernova> <1192520674.3687.1.camel@uberpc.marples.name> <1192543696.1173.18.camel@uberlaptop.development.ltl> Content-Type: text/plain Organization: Gentoo Date: Wed, 17 Oct 2007 12:26:20 +0100 Message-Id: <1192620380.12390.16.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: a86cf009-e8c0-445a-aef1-168cff0bcb93 X-Archives-Hash: a46721b50e34fd71074e8f8354562eb1 On Wed, 2007-10-17 at 10:15 +0100, Steve Long wrote: > OK, that's all good, and you're _right_ for this case. I guess I was trying > to show an array being used since it came up before. For instance, I often > add to a global array with eg failed+=("$1"), which I might display > one-per-line to the user with: IFS=$'\n'; echo "${failed[*]}". This is > handy for tab separated data as well, if one uses IFS=$'\t' (also affects > read.) Or you could just echo to stderr (echo "failed $1" >&2) > > I maybe wrong, but shouldn't you be using == inside [[ ]]? > > > No. == works, but = is considered better script style in #bash since it's > the same as standard [ and implies you know you're in shell, not C. No, you're in *bash*. Therein lies the difference. > I use > it since it's the script I see in front of me all the time, and it's _less > typing_. == is required in ((..)) (For the BASH additions, *and* how to > stay compatible see [1].) So == is sometimes required? Don't you find it confusing? As to staying compatible, you've already lost as you're just compatible with bash. > The thing is bashisms make my life easier: the code is clearer, and easier > to comprehend, write and maintain. While ebuilds aren't full-blown > applications, the same principles apply to the script, especially when so > few devs have to maintain so many ebuilds. IMO script that takes twice as > long to parse and write is a Bad Thing (tm): even if it only adds a minute > or two to the average quick fix, across the tree that adds up. Given how this started off, I would say that bash makes your life overly complex, not easier. But of course, that's my opinion. > So given that the Unix world, while still supporting POSIX as a base, also > has added other, newer standards, I don't see the benefit in not using > them. I agree, but as I've already demonstrated you don't have to use them just because they're there. If you have to tools, functions or whatever that do the same job and one is POSIX and one is not, which one would you pick? Would you be influenced in any way if the one that is not happens to be supplied by a favourite tool of yours, like say bash? > The only use-case that made any sense to me was someone using > OpenMoko, or a Motorola phone with its own complete Linux (as opposed to > the usual embedded space.) IMO someone who bothers to install a full blown > Linux on a phone will have a desktop they can use as Build host, and a > better use of dev time is to write the tools to enable that (it'd also be a > lot quicker), than to convert all the ebuilds to sh, and slow future dev > down by making devs use sh syntax. I disagree that development would be any slower. > > It's funny: there is actually a lot of emphasis given in #bash on > portability. People are routinely told not to rely on GNU command options, > and there is even occasional discussion of sh. It's just that bash runs on > so many platforms (including greycat's crusty HP-UX from 1995) and has > become a de-facto standard: if people use other shells, those also > typically support constructs like arrays, and usually add even more, > non-POSIX, stuff than bash. Consistency is wonderful yes? You're advising to rely on one GNU tool but shun others? hehehehe Thanks Roy -- gentoo-dev@gentoo.org mailing list