[gentoo-dev] Re: 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

[Steve Long]

Roy Marples wrote:
> 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)
>
Yeah I do that as well, but you know what users are like, we need info
repeated ;P
I actually echo the list after every package, but with no IFS setting so it
appears on one line. That's because the normal output is what I find useful
during emerge sessions, and as no-one's asked for any changes to it.

>> > 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.
>
Well it's still a shell. Certainly feels very different to C (and supports
all your finicky syntax ;)

>>  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?
No, because the only time I use == is in ((..)) which is already vastly
different. And for a C coder, ((..)) is easy.

> As to staying compatible, you've already lost as you're just compatible
> with bash.
>
Er OK, but learning bash doesn't mean you can't also learn how to use sh for
the odd occasion when work demands it.

>> 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.
>
I'm just discussing ease of writing and maintaining script. I don't see how
the context affects this?

>> 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?
>
Heh, I only learnt bash in January. I've wanted to learn shellscripting for
*years*, and since Gentoo used bash, and I was told freenode #bash was the
place to learn it, I started using IRC for the first time in my life; so
I'm not a long-time bash user. It does form part of my thinking now, I'll
admit, but only because it gave me all the constructs I am used to in C,
and less so than awk, which I have used for much longer. [[ also has things
that make it more familiar to C coders (like && instead of -a, which some
old-time scripters [guess;] find annoying) so it makes sense that it would
allow == to ease the learning curve.

And the point still stands: there has been progress since Posix: many apps
use _GNU_SOURCE for instance, and I for one would be unhappy about a system
where I couldn't use _X_OPEN_SOURCE. So we're not talking about
a "Posix-or-not" choice; Posix is a *base* level, not an aspiration (any
longer.)

> I disagree that development would be any slower.
>
As you said, opinions. Some of the sh examples you have given are much
trickier to grok and write, in mine. As such, I believe that restricting
usage to the Shell Command Language base level of POSIX, would slow future
maintenance down.

>>
>> 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
>
No: like I said, that's the apparent consensus in #bash. I don't happen to
agree with it, since I think GNU tools can run pretty much anywhere, and
have no commercial or political downside. My point was that bash forms more
of a portable, next-gen standard than the whole GNU userland (and that
actually greycat would agree with your crusade against GNU tools ;) -- just
don't ever tell him you're a Gentoo dev, cos he *hates* Gentoo, hehe.)

Regards,
Steve.


-- 
gentoo-dev@g.o mailing list