| 1 |
On Wed, 2007-10-17 at 10:15 +0100, Steve Long wrote: |
| 2 |
> OK, that's all good, and you're _right_ for this case. I guess I was trying |
| 3 |
> to show an array being used since it came up before. For instance, I often |
| 4 |
> add to a global array with eg failed+=("$1"), which I might display |
| 5 |
> one-per-line to the user with: IFS=$'\n'; echo "${failed[*]}". This is |
| 6 |
> handy for tab separated data as well, if one uses IFS=$'\t' (also affects |
| 7 |
> read.) |
| 8 |
|
| 9 |
Or you could just echo to stderr (echo "failed $1" >&2) |
| 10 |
|
| 11 |
|
| 12 |
> > I maybe wrong, but shouldn't you be using == inside [[ ]]? |
| 13 |
> > |
| 14 |
> No. == works, but = is considered better script style in #bash since it's |
| 15 |
> the same as standard [ and implies you know you're in shell, not C. |
| 16 |
|
| 17 |
No, you're in *bash*. Therein lies the difference. |
| 18 |
|
| 19 |
> I use |
| 20 |
> it since it's the script I see in front of me all the time, and it's _less |
| 21 |
> typing_. == is required in ((..)) (For the BASH additions, *and* how to |
| 22 |
> stay compatible see [1].) |
| 23 |
|
| 24 |
So == is sometimes required? Don't you find it confusing? |
| 25 |
As to staying compatible, you've already lost as you're just compatible |
| 26 |
with bash. |
| 27 |
|
| 28 |
> The thing is bashisms make my life easier: the code is clearer, and easier |
| 29 |
> to comprehend, write and maintain. While ebuilds aren't full-blown |
| 30 |
> applications, the same principles apply to the script, especially when so |
| 31 |
> few devs have to maintain so many ebuilds. IMO script that takes twice as |
| 32 |
> long to parse and write is a Bad Thing (tm): even if it only adds a minute |
| 33 |
> or two to the average quick fix, across the tree that adds up. |
| 34 |
|
| 35 |
Given how this started off, I would say that bash makes your life overly |
| 36 |
complex, not easier. But of course, that's my opinion. |
| 37 |
|
| 38 |
> So given that the Unix world, while still supporting POSIX as a base, also |
| 39 |
> has added other, newer standards, I don't see the benefit in not using |
| 40 |
> them. |
| 41 |
|
| 42 |
I agree, but as I've already demonstrated you don't have to use them |
| 43 |
just because they're there. If you have to tools, functions or whatever |
| 44 |
that do the same job and one is POSIX and one is not, which one would |
| 45 |
you pick? Would you be influenced in any way if the one that is not |
| 46 |
happens to be supplied by a favourite tool of yours, like say bash? |
| 47 |
|
| 48 |
|
| 49 |
> The only use-case that made any sense to me was someone using |
| 50 |
> OpenMoko, or a Motorola phone with its own complete Linux (as opposed to |
| 51 |
> the usual embedded space.) IMO someone who bothers to install a full blown |
| 52 |
> Linux on a phone will have a desktop they can use as Build host, and a |
| 53 |
> better use of dev time is to write the tools to enable that (it'd also be a |
| 54 |
> lot quicker), than to convert all the ebuilds to sh, and slow future dev |
| 55 |
> down by making devs use sh syntax. |
| 56 |
|
| 57 |
I disagree that development would be any slower. |
| 58 |
|
| 59 |
> |
| 60 |
> It's funny: there is actually a lot of emphasis given in #bash on |
| 61 |
> portability. People are routinely told not to rely on GNU command options, |
| 62 |
> and there is even occasional discussion of sh. It's just that bash runs on |
| 63 |
> so many platforms (including greycat's crusty HP-UX from 1995) and has |
| 64 |
> become a de-facto standard: if people use other shells, those also |
| 65 |
> typically support constructs like arrays, and usually add even more, |
| 66 |
> non-POSIX, stuff than bash. |
| 67 |
|
| 68 |
Consistency is wonderful yes? You're advising to rely on one GNU tool |
| 69 |
but shun others? hehehehe |
| 70 |
|
| 71 |
Thanks |
| 72 |
|
| 73 |
Roy |
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives