Roy Marples wrote:
> On Tue, 2007-10-16 at 13:38 +0100, Steve Long wrote:
>> Roy Marples wrote:
>> > On Tue, 2007-10-16 at 00:28 -0700, Donnie Berkholz wrote:
>> >> On 08:19 Tue 16 Oct , Steve Long wrote:
>> >> > stdDocs=(ChangeLog AUTHORS FEATURES THANKS README CodingStyle TODO
>> >> > FAQ)
>> >> >
>> >> > stdDoc() {
>> >> > local d l=()
>> >> > for d in "[EMAIL PROTECTED]"; do
>> >> > [[ -f $d ]] && l+=("$d")
>> >> > done
>> >> > (([EMAIL PROTECTED])) && dodoc "[EMAIL PROTECTED]"
>> >> > }
>> >> >
>> >> > (assuming [[ $PWD = $S ]] or whichever is the right one for docs.)
>> >>
>> >> Is it just me, or is this code way more complex than it needs to be?
>> >> It looks like bashturbation to me. =P
>> >
>> LMAO. It's as complex as it needs to be to handle filenames with spaces
>> or any other character in. Remember: "Looks like it needs quotes there..
>> $D, $S.." What, I should write crap script for this esteemed audience,
>> cos you only currently deal with filenames without spaces? ;P
>
> No, it's overly complex. Consider this
>
> stddoc() {
> local d
> for d in ChangeLog AUTHORS FEATURES THANKS README \
> CodingStyle TODO FAQ; do
> [ -f "${d}" ] && dodoc "${f}"
> done
> }
>
> Want spaces?
>
> stddoc() {
> local d
> for d in ChangeLog AUTHORS FEATURES THANKS README \
> CodingStyle TODO FAQ "a file with spaces"; do
> [ -f "${d}" ] && dodoc "${f}"
> done
> }
>
> Or maybe you want to do it on one hit?
>
> stddoc() {
> local d
> set --
> for d in ChangeLog AUTHORS FEATURES THANKS README \
> CodingStyle TODO FAQ "a file with spaces"; do
> [ -f "${d}" ] && set -- "$@" "${f}"
> done
> dodoc "$@"
> }
>
>
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.)
The use of an array like that still seem pertinent to me: for instance in an
eclass as something the ebuild can add to, or indeed as a dataset the
eclass builds up in cooperation with the ebuild. An example of that might
be checking php use flags; the ebuild is only interested in a subset, and
the eclass would only run the checks on those.
In any event it's a useful construct imo, for a set that can be added to as
and when.
>> > You can also do some pattern matching like so
>> >
>> > foo="foo foobar"
>> >
>> > [ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar"
>> [[ $foo = *foobar ]] && echo "ends with foobar"
>>
>> > [ "${foo#foobar}" = "${foo}" ] || echo "starts with foo"
>> [[ $foo = foo* ]] && echo 'oh does it?'
>> There's no need for borked script that is counter-intuitive, and doesn't
>> have a third of the functionality either.
>
> 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. 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].)
>> [[ $foo = *'wow it '*"does as $well"* ]] && echo 'And a whole lot more!'
>
> case "${foo}" in
> *'wow it '*"does as $well"*) && echo "whatever you can do i can do in
> sh";;
> esac
>
>> Or should *nix only ever support
>> POSIX APIs for everything? #define _X_OPEN_SOURCE? No? Hmm.. *shrug* ;>
>
> No, I saying use whatever god given extensions you like. But if there's
> a portable way of doing the same thing then please use the portable way
> of doing 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.
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. 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.
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.
>> /me wanders down the pub.. *plop*
>
> Yeah, I'd drown my sorrows if I wrote shell script like you :P
>
Lol, yeah well I would if i had to write in sh, it's rough! ;) Each to their
own, eh?
Regards,
igli.
[1] http://wooledge.org/mywiki/ArithmeticExpression
--
[EMAIL PROTECTED] mailing list
