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

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

[Donnie Berkholz]

On 18:05 Sun 14 Oct     , Konstantin Arkhipov (voxus) wrote:
> 1.1                  dev-php5/onphp/onphp-0.10.6.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&content-type=text/plain

> 	if use doc ; then
> 		for doc in `find doc -maxdepth 1 -type f -print` ; do
> 			dodoc ${doc}
> 		done

You could avoid all these calls to dodoc by saving the docs in a 
variable, then calling dodoc on it. Another option could be to send the 
loop output to 'xargs dodoc'.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Konstantin V. Arkhipov]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Monday 15 October 2007 01:11:25 Donnie Berkholz wrote:
> On 18:05 Sun 14 Oct     , Konstantin Arkhipov (voxus) wrote:
> > 1.1                  dev-php5/onphp/onphp-0.10.6.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10
> >.6.ebuild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10
> >.6.ebuild?rev=1.1&content-type=text/plain
> >
> > 	if use doc ; then
> > 		for doc in `find doc -maxdepth 1 -type f -print` ; do
> > 			dodoc ${doc}
> > 		done
>
> You could avoid all these calls to dodoc by saving the docs in a
> variable, then calling dodoc on it. Another option could be to send the
> loop output to 'xargs dodoc'.

thank you, will fix this soon.

-- 
voxus
:wq

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 18:05 Sun 14 Oct     , Konstantin Arkhipov (voxus) wrote:
> > 1.1                  dev-php5/onphp/onphp-0.10.6.ebuild
> > 
> > file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&view=markup
> > plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&content-type=text/plain
> 
> > 	if use doc ; then
> > 		for doc in `find doc -maxdepth 1 -type f -print` ; do
> > 			dodoc ${doc}
> > 		done
> 
> You could avoid all these calls to dodoc by saving the docs in a 
> variable, then calling dodoc on it. Another option could be to send the 
> loop output to 'xargs dodoc'.

Or, since you already have the command substitution there, how about:

	dodoc `find doc -maxdepth 1 -type f`


-- 
Major premise: You can't handle the truth.
Minor premise: The truth is out there.
Conclusion: You can't handle what is out there.

[-- Attachment #2: Type: application/pgp-signature, Size: 206 bytes --]

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

[Donnie Berkholz]

On 16:52 Sun 14 Oct     , Drake Wyrm wrote:
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 18:05 Sun 14 Oct     , Konstantin Arkhipov (voxus) wrote:
> > > 1.1                  dev-php5/onphp/onphp-0.10.6.ebuild
> > > 
> > > file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&view=markup
> > > plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/onphp/onphp-0.10.6.ebuild?rev=1.1&content-type=text/plain
> > 
> > > 	if use doc ; then
> > > 		for doc in `find doc -maxdepth 1 -type f -print` ; do
> > > 			dodoc ${doc}
> > > 		done
> > 
> > You could avoid all these calls to dodoc by saving the docs in a 
> > variable, then calling dodoc on it. Another option could be to send the 
> > loop output to 'xargs dodoc'.
> 
> Or, since you already have the command substitution there, how about:
> 
> 	dodoc `find doc -maxdepth 1 -type f`

Much better than what I said.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas de Grenier de Latour]

On 2007/10/14, Drake Wyrm <wyrm@haell.com> wrote:

> Or, since you already have the command substitution there, how about:
> 
> 	dodoc `find doc -maxdepth 1 -type f`

Or even better, how about explicitly listing the relevant files
(ChangeLog, AUTHORS, FEATURES, THANKS, README, CodingStyle, TODO and
FAQ) and avoid the useless ones (Doxyfile, onphp.doxy.php and LICENSE)?

And also, given the kind of files being there, what about moving
this block out of the "use doc" conditional?

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

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

Thomas de Grenier de Latour wrote:

> On 2007/10/14, Drake Wyrm <wyrm@haell.com> wrote:
> 
>> Or, since you already have the command substitution there, how about:
>> 
>> dodoc `find doc -maxdepth 1 -type f`
> 
> Or even better, how about explicitly listing the relevant files
> (ChangeLog, AUTHORS, FEATURES, THANKS, README, CodingStyle, TODO and
> FAQ) and avoid the useless ones (Doxyfile, onphp.doxy.php and LICENSE)?
> 
> And also, given the kind of files being there, what about moving
> this block out of the "use doc" conditional?
> 
The `useless' ones are the ones I would expect to get installed if I set doc
USE flag (apart from LICENSE which already exists on the local machine.)

I agree the others should be installed unconditionally, and it might be
useful to have a standard list that dodoc (or some other fn) checks, eg: 

stdDocs=(ChangeLog AUTHORS FEATURES THANKS README CodingStyle TODO FAQ)

stdDoc() {
        local d l=()
        for d in "${stdDocs[@]}"; do
                [[ -f $d ]] && l+=("$d")
        done
        ((${#l[@]})) && dodoc "${l[@]}"
}

(assuming [[ $PWD = $S ]] or whichever is the right one for docs.)


-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

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 "${stdDocs[@]}"; do
>                 [[ -f $d ]] && l+=("$d")
>         done
>         ((${#l[@]})) && dodoc "${l[@]}"
> }
> 
> (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

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Roy Marples]

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 "${stdDocs[@]}"; do
> >                 [[ -f $d ]] && l+=("$d")
> >         done
> >         ((${#l[@]})) && dodoc "${l[@]}"
> > }
> > 
> > (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

Nope, it looks like milk and cereal decorating my monitor to me; after
reading that! :)

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] 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 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 "${stdDocs[@]}"; do
>> >                 [[ -f $d ]] && l+=("$d")
>> >         done
>> >         ((${#l[@]})) && dodoc "${l[@]}"
>> > }
>> > 
>> > (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
 
> Nope, it looks like milk and cereal decorating my monitor to me; after
> reading that! :)
>
Hmm..
> 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?'

> [ "${foo#* }" = "${foo}" ] || echo "has a space"
>
[[ $foo = *'wow it '*"does as $well"* ]] && echo 'And a whole lot more!'

> So there's no need for convoluted nested case statements.

There's no need for borked script that is counter-intuitive, and doesn't
have a third of the functionality either. Or should *nix only ever support
POSIX APIs for everything? #define _X_OPEN_SOURCE? No? Hmm.. *shrug* ;>

/me wanders down the pub.. *plop*

-- 
gentoo-dev@gentoo.org mailing list

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

[Roy Marples]

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 "${stdDocs[@]}"; do
> >> >                 [[ -f $d ]] && l+=("$d")
> >> >         done
> >> >         ((${#l[@]})) && dodoc "${l[@]}"
> >> > }
> >> > 
> >> > (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 "$@"
}


> > 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 [[ ]]?

> [[ $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.

> /me wanders down the pub.. *plop*

Yeah, I'd drown my sorrows if I wrote shell script like you :P

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[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

[Steve Long]

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 "${stdDocs[@]}"; do
>> >> >                 [[ -f $d ]] && l+=("$d")
>> >> >         done
>> >> >         ((${#l[@]})) && dodoc "${l[@]}"
>> >> > }
>> >> > 
>> >> > (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


-- 
gentoo-dev@gentoo.org mailing list

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

[Roy Marples]

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

[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@gentoo.org mailing list

Re: [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

[Marius Mauch]

Is it just me, or has this thread gone beyond it's usefulness?
IOW, I think you two should take this (and future bash vs. sh
discussions) to a private channel.

Marius
-- 
gentoo-dev@gentoo.org mailing list