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 -- [EMAIL PROTECTED] mailing list
