[gentoo-dev] Opinions Wanted - Arrays again :)

[gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

Hello List

It's your favourite posix shell lover here, asking for your honest
opinions.

array="1.2.3.4 netmask 5.6.7.8;
\*
'host.name' netmask 1.2.3.4
-I 'option; $FOO with spaces'
"

array=("1.2.3.4 netmask 5.6.7.8;"
"\*"
"'host.name' netmask 1.2.3.4"
"-I 'option; $FOO with spaces'"
)

array="'1.2.3.4 netmask 5.6.7.8;' \
'\*' \
\"'host.name' netmask 1.2.3.4\" \
\"-I 'option; $FOO with spaces'\"
"

The first and last are of course posix constructs whilst the middle is
bash.

The bash one is purely there for reference, and of course you can still
use it if /bin/sh is bash. The last one is what baselayout-2 currently
uses and I'm wondering if we should switch to the first one before we
come out of package.mask.

I'm asking which you think are the most readable of the first and last
ones and if you see any issues with either.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy Marples wrote:
> Hello List
> 
> It's your favourite posix shell lover here, asking for your honest
> opinions.
> 
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'
> "
> 
> array=("1.2.3.4 netmask 5.6.7.8;"
> "\*"
> "'host.name' netmask 1.2.3.4"
> "-I 'option; $FOO with spaces'"
> )
> 
> array="'1.2.3.4 netmask 5.6.7.8;' \
> '\*' \
> \"'host.name' netmask 1.2.3.4\" \
> \"-I 'option; $FOO with spaces'\"
> "
> 
> The first and last are of course posix constructs whilst the middle is
> bash.
> 
> The bash one is purely there for reference, and of course you can still
> use it if /bin/sh is bash. The last one is what baselayout-2 currently
> uses and I'm wondering if we should switch to the first one before we
> come out of package.mask.
> 
> I'm asking which you think are the most readable of the first and last
> ones and if you see any issues with either.

These sh ``arrays'' are really just strings, right? Did you implement
functions to take them apart? Can the same function handle forms 1 and 3?

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIL4Bp/VmCx0OL2wRAszVAJ9gKSxDq+D4QlppCw+vHzKtCTq5DQCfUa0m
lxNxzVbipBXBcPL+6G2vGyY=
=bBAt
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 18:02 +0200, Marijn Schouten (hkBst) wrote:
> These sh ``arrays'' are really just strings, right? Did you implement
> functions to take them apart? Can the same function handle forms 1 and 3?

I don't think we could use both.
Here's a code snippet of actually using them

# How baselayout-2 presently handles arrays
eval "$(_get_array array)"
for x in "$@"; do
    echo "$x"
done

# How baselayout-2 may handle arrays based on this discussion
IFS="
"
for x in $(_get_array array); do
    unset IFS
    echo "$x"
done

Assume that the _get_array function correctly maps the bash array to the
posix shell one in both cases.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Ioannis Aslanidis]

Form #1 looks clearer than #3, but still not so clear :)

On 10/25/07, Roy Marples <uberlord@gentoo.org> wrote:
>
> On Thu, 2007-10-25 at 18:02 +0200, Marijn Schouten (hkBst) wrote:
> > These sh ``arrays'' are really just strings, right? Did you implement
> > functions to take them apart? Can the same function handle forms 1 and 3?
>
> I don't think we could use both.
> Here's a code snippet of actually using them
>
> # How baselayout-2 presently handles arrays
> eval "$(_get_array array)"
> for x in "$@"; do
>     echo "$x"
> done
>
> # How baselayout-2 may handle arrays based on this discussion
> IFS="
> "
> for x in $(_get_array array); do
>     unset IFS
>     echo "$x"
> done
>
> Assume that the _get_array function correctly maps the bash array to the
> posix shell one in both cases.
>
> Thanks
>
> Roy
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


-- 
Ioannis Aslanidis

<deathwing00[at]gentoo.org> 0xB9B11F4E
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 17:18 +0100, Roy Marples wrote:
> # How baselayout-2 may handle arrays based on this discussion
> IFS="
> "
> for x in $(_get_array array); do
>     unset IFS
>     echo "$x"
> done

Also, if we didn't need to actually set any variables outside the loop
we could also then write this

_get_array array | while read x; do
  echo "$x"
done

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Josh Saddler]

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

Roy Marples wrote:
> Hello List
> 
> It's your favourite posix shell lover here, asking for your honest
> opinions.
> 
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'
> "
> 
> array=("1.2.3.4 netmask 5.6.7.8;"
> "\*"
> "'host.name' netmask 1.2.3.4"
> "-I 'option; $FOO with spaces'"
> )
> 
> array="'1.2.3.4 netmask 5.6.7.8;' \
> '\*' \
> \"'host.name' netmask 1.2.3.4\" \
> \"-I 'option; $FOO with spaces'\"
> "
> 
> The first and last are of course posix constructs whilst the middle is
> bash.
> 
> The bash one is purely there for reference, and of course you can still
> use it if /bin/sh is bash. The last one is what baselayout-2 currently
> uses and I'm wondering if we should switch to the first one before we
> come out of package.mask.
> 
> I'm asking which you think are the most readable of the first and last
> ones and if you see any issues with either.

The first is much more readable than the last, but only slightly more
readable than the middle one. I'm not a sh/bash guru the way many of the
developers are, and I can tell you right up front that I'd be more
comfortable configuring options if they looked more like the first
example, and I'd guess many users would feel the same way. The fewer " '
; \ characters there are to keep track of, the better.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Donnie Berkholz]

On 16:40 Thu 25 Oct     , Roy Marples wrote:
> Hello List
> 
> It's your favourite posix shell lover here, asking for your honest
> opinions.
> 
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'
> "
> 
> array=("1.2.3.4 netmask 5.6.7.8;"
> "\*"
> "'host.name' netmask 1.2.3.4"
> "-I 'option; $FOO with spaces'"
> )
> 
> array="'1.2.3.4 netmask 5.6.7.8;' \
> '\*' \
> \"'host.name' netmask 1.2.3.4\" \
> \"-I 'option; $FOO with spaces'\"
> "
> 
> The first and last are of course posix constructs whilst the middle is
> bash.
> 
> The bash one is purely there for reference, and of course you can still
> use it if /bin/sh is bash. The last one is what baselayout-2 currently
> uses and I'm wondering if we should switch to the first one before we
> come out of package.mask.
> 
> I'm asking which you think are the most readable of the first and last
> ones and if you see any issues with either.

Is there any way we could avoid these altogether, and instead use 
separate variables for each array element?

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

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 14:31 -0700, Donnie Berkholz wrote:
> Is there any way we could avoid these altogether, and instead use 
> separate variables for each array element?

Well, we could prefix with numbers

array="1.2.3.4 netmask 5.6.7.8;
\*
'host.name' netmask 1.2.3.4
-I 'option; $FOO with spaces'"

Would become

0_config_eth0="1.2.3.4 netmask 5.6.7.8;"
1_config_eth0="\*"
2_config_eth0="'host.name' netmask 1.2.3.4"
3_config_eth0="-I 'option; $FOO with spaces'"

Can't suffix as we use $IFACE and $SSID and sometimes hardware addresses
there. We don't have to have 0_, but we would need the other numbers.
Advantage - no messy holding an array in a string
Disadvantage - you have a big array and need to punt something in the
middle :) OK, you could put a "value" in there but each array loop would
have to know about this magical value.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Donnie Berkholz]

On 22:49 Thu 25 Oct     , Roy Marples wrote:
> On Thu, 2007-10-25 at 14:31 -0700, Donnie Berkholz wrote:
> > Is there any way we could avoid these altogether, and instead use 
> > separate variables for each array element?
> 
> Well, we could prefix with numbers
> 
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'"
> 
> Would become
> 
> 0_config_eth0="1.2.3.4 netmask 5.6.7.8;"
> 1_config_eth0="\*"
> 2_config_eth0="'host.name' netmask 1.2.3.4"
> 3_config_eth0="-I 'option; $FOO with spaces'"

I was hoping for some sort of meaningfully named separate variables, not 
an even messier fake array.

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

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 15:56 -0700, Donnie Berkholz wrote:
> On 22:49 Thu 25 Oct     , Roy Marples wrote:
> > On Thu, 2007-10-25 at 14:31 -0700, Donnie Berkholz wrote:
> > > Is there any way we could avoid these altogether, and instead use 
> > > separate variables for each array element?
> > 
> > Well, we could prefix with numbers
> > 
> > array="1.2.3.4 netmask 5.6.7.8;
> > \*
> > 'host.name' netmask 1.2.3.4
> > -I 'option; $FOO with spaces'"
> > 
> > Would become
> > 
> > 0_config_eth0="1.2.3.4 netmask 5.6.7.8;"
> > 1_config_eth0="\*"
> > 2_config_eth0="'host.name' netmask 1.2.3.4"
> > 3_config_eth0="-I 'option; $FOO with spaces'"
> 
> I was hoping for some sort of meaningfully named separate variables, not 
> an even messier fake array.

I'm all ears for any other suggestions :)

BTW, my example fails as shell does not allow numbers to prefix variable
names. Would have to be something like a0_ a1_

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Richard Freeman]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy Marples wrote:
>>> 0_config_eth0="1.2.3.4 netmask 5.6.7.8;"
>>> 1_config_eth0="\*"
>>> 2_config_eth0="'host.name' netmask 1.2.3.4"
>>> 3_config_eth0="-I 'option; $FOO with spaces'"
>> I was hoping for some sort of meaningfully named separate variables, not 
>> an even messier fake array.
> 
> I'm all ears for any other suggestions :)
> 

If there is some problem with this suggestion feel free to shoot it full
of holes, but how about something like:

address_eth0="1.2.3.4"
netmask_eth0="255.255.255.0"
broadcast_eth0="1.2.3.255"
gateway_eth0="1.2.3.1"
network_eth0="1.2.3.0"
hostname_eth0="mypc"
options_eth0="bells and whistles"

Without digging through the original source I'm not sure what everything
else in that array is, but I think you get the picture.  Instead of
sticking all these parameters into a big array why not break them down
into what they actually are used for?  This should also make the code
that actually reads back these variables a lot more readable - instead
of wondering what the 5th field in the array is you would see something
meaningful like "netmask".

Again, if I'm missing some reason why this wouldn't work feel free to
point it out.  :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIb6OG4/rWKZmVWkRAhvzAJ0eoNK8I73+HU3tVRnJzFMJwYKSqQCgqzoW
j71E+DxgfrGTRSwKWgCmW40=
=qitq
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Fri, 2007-10-26 at 06:16 -0400, Richard Freeman wrote:
> If there is some problem with this suggestion feel free to shoot it full
> of holes, but how about something like:
> 
> address_eth0="1.2.3.4"
> netmask_eth0="255.255.255.0"
> broadcast_eth0="1.2.3.255"
> gateway_eth0="1.2.3.1"
> network_eth0="1.2.3.0"
> hostname_eth0="mypc"
> options_eth0="bells and whistles"

How would you construct that if you wanted to add 5 addresses to the
interface?

> Without digging through the original source I'm not sure what everything
> else in that array is, but I think you get the picture.  Instead of
> sticking all these parameters into a big array why not break them down
> into what they actually are used for?  This should also make the code
> that actually reads back these variables a lot more readable - instead
> of wondering what the 5th field in the array is you would see something
> meaningful like "netmask".

We don't care what the actual options or values are, they are merely
passed to ifconfig. Basically we need the equivalent of doing this

ifconfig eth0 1.2.3.4 netmask 5.6.7.8 broadcast 1.2.3.4
ifconfig eth0 5.6.7.8 netmask 1.2.3.4 broadcast 5.6.7.8
ifconfig eth0 maybe some undocumented command

And we do this with a few other tools as well. Lets take a list of
preferred wireless AP's to connect to. How would you have that? As the
only invalid character in an SSID is a NULL (daft, but I didn't write
the specification)

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Duncan]

Roy Marples <uberlord@gentoo.org> posted
1193395366.4312.14.camel@uberlaptop.marples.name, excerpted below, on 
Fri, 26 Oct 2007 11:42:46 +0100:

> On Fri, 2007-10-26 at 06:16 -0400, Richard Freeman wrote:
>> [H]ow about something like:
>> 
>> address_eth0="1.2.3.4"
>> netmask_eth0="255.255.255.0"
>> broadcast_eth0="1.2.3.255"
[...]
>> options_eth0="bells and whistles"
> 
> How would you construct that if you wanted to add 5 addresses to the
> interface?

>> I think you get the picture. 

> We don't care what the actual options or values are, they are merely
> passed to ifconfig. Basically we need the equivalent of doing this
> 
> ifconfig eth0 1.2.3.4 netmask 5.6.7.8 broadcast 1.2.3.4 
> ifconfig eth0 5.6.7.8 netmask 1.2.3.4 broadcast 5.6.7.8
> ifconfig eth0 maybe some undocumented command
> 
> And we do this with a few other tools as well. Lets take a list of
> preferred wireless AP's to connect to. How would you have that? As the
> only invalid character in an SSID is a NULL (daft, but I didn't write
> the specification)

Well, several services already have a "basic" setup using named vars, 
then something like Richard's suggested Options_eth0= as a (normally 
commented) catch-all for anything advanced that the admin wishes to pass 
"raw".  IMO the standard network stuff is well defined enough for that, 
perhaps with a couple of mode-toggles and/or counters thrown in.  (A 
counter like eth0_number_IPs= could default to one, for instance, but set 
to something higher and with the appropriate number of address_N_eth0= 
lines, it'd then cover your 5-address example, without having to worry 
about figuring out how many there are, since it's a given.)

I think that's what many of us would like and what this subthread is 
asking for, truth be told, but I also realize it's going to be more work 
setting it up -- but OTOH should be simpler for the user to setup so 
perhaps less bugs to deal with and the documentation in the net sample 
file should be somewhat simpler as well.  The more work thing is why I've 
not requested it before, but it'd be nice, and with others mentioning it 
now too, now's the time to speak up if I'm going to. =8^)

As for the wireless side, I've stuck to wired for all the usual reasons, 
so don't even pretend to know anything about wireless, nor to offer any 
sort of solution.  Perhaps even if the standard networking is setup with 
named vars, the wireless example you gave would be better left as 
"arrays" of whatever form?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Roy Marples]

On Fri, 2007-10-26 at 16:36 +0000, Duncan wrote:
> Well, several services already have a "basic" setup using named vars, 
> then something like Richard's suggested Options_eth0= as a (normally 
> commented) catch-all for anything advanced that the admin wishes to pass 
> "raw".  IMO the standard network stuff is well defined enough for that, 
> perhaps with a couple of mode-toggles and/or counters thrown in.  (A 
> counter like eth0_number_IPs= could default to one, for instance, but set 
> to something higher and with the appropriate number of address_N_eth0= 
> lines, it'd then cover your 5-address example, without having to worry 
> about figuring out how many there are, since it's a given.)
> 
> I think that's what many of us would like and what this subthread is 
> asking for, truth be told, but I also realize it's going to be more work 
> setting it up -- but OTOH should be simpler for the user to setup so 
> perhaps less bugs to deal with and the documentation in the net sample 
> file should be somewhat simpler as well.  The more work thing is why I've 
> not requested it before, but it'd be nice, and with others mentioning it 
> now too, now's the time to speak up if I'm going to. =8^)

Fair enough, but one of the goals of baselayout-2 is to support
baselayout-1 configs where possible if the shell is still bash.

I'm striving to support similar configs for non bash shells so that
there's not much of a learning curve.

Yes we could have a totally new non compatible setup, but that would
really suck hard for upgraders yes?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Duncan]

Roy Marples <uberlord@gentoo.org> posted
1193418183.3487.3.camel@uberpc.marples.name, excerpted below, on  Fri, 26
Oct 2007 18:03:03 +0100:

> Fair enough, but one of the goals of baselayout-2 is to support
> baselayout-1 configs where possible if the shell is still bash.
> 
> I'm striving to support similar configs for non bash shells so that
> there's not much of a learning curve.
> 
> Yes we could have a totally new non compatible setup, but that would
> really suck hard for upgraders yes?

Unless I misunderstood something, and as certainly the example you gave 
showed, backward compatibility would be pretty simple: just throw the 
entire array in the eth0_extra_options= line or whatever.

Besides, the idea is that the vars should be almost self-documenting for 
at least the "simple" setups, so while there'd certainly be a conversion 
necessary, for those "simple" setups, it should be as easy to explain 
that as it will be/is to explain the rules for converting to arrays and 
have them get it right (said as one who has done the conversion to the 
present baselayout-2 format and screwed up something dumb in the 
process).  Converting the somewhat "magic" array from one form to 
another, due to that "magic", is going to be more error prone than 
converting to vars of the type Gentoo users already use every day, each 
with a single defined purpose, no fancy format necessary.  That's for the 
"simple" setups.  The more complex setups by definition should have folks 
that understand those setups well enough to do the conversion without 
major issue, since they pretty much had to in ordered to create them in 
the first place.

So after implementing individual vars, there should be two viable options 
for upgrading users.  (1) Simply stick the array in the _extra_options 
vars with only minimal (if any) format changes, or break it up into the 
individual values.  Presumably the individual values would be recommended 
as the supported choice going forward, but the shove-it-all-in-the-
options option would be there as well, for those who didn't want to 
bother with more at that moment.

Of course, that's still assuming the folks actually doing the baselayout2 
work (you, and I'm not sure how many others working with you) ultimately 
decide that it's worth the trouble to change.  I do honestly believe from 
a user perspective it'll be easier to maintain and thus more trouble-free 
if an individual values setup is ultimately chosen, but it's certainly 
more work to setup from an implementation perspectiv, and very pointedly, 
I'm not the one doing that work, so it's very easy for me to sit here and 
get all fancy about how it "should" be done. =8^)  IOW, it's very much 
your call.  You just asked for opinions and I'm happily giving mine. =8^)

Of course, as I'm already on baselayout2, I'll be bug testing whatever is 
ultimately decided. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Roy Marples]

On Fri, 2007-10-26 at 18:57 +0000, Duncan wrote:
> Roy Marples <uberlord@gentoo.org> posted
> 1193418183.3487.3.camel@uberpc.marples.name, excerpted below, on  Fri, 26
> Oct 2007 18:03:03 +0100:
> 
> > Fair enough, but one of the goals of baselayout-2 is to support
> > baselayout-1 configs where possible if the shell is still bash.
> > 
> > I'm striving to support similar configs for non bash shells so that
> > there's not much of a learning curve.
> > 
> > Yes we could have a totally new non compatible setup, but that would
> > really suck hard for upgraders yes?
> 
> Unless I misunderstood something, and as certainly the example you gave 
> showed, backward compatibility would be pretty simple: just throw the 
> entire array in the eth0_extra_options= line or whatever.

Not really, as we have a function that maps the existing bash array into a posix shell equivalent.

> So after implementing individual vars, there should be two viable options 
> for upgrading users.  (1) Simply stick the array in the _extra_options 
> vars with only minimal (if any) format changes, or break it up into the 
> individual values.  Presumably the individual values would be recommended 
> as the supported choice going forward, but the shove-it-all-in-the-
> options option would be there as well, for those who didn't want to 
> bother with more at that moment.

One issue with that is there is no automatic way of doing that. We just
pass the array elements onto the various programs

config_eth0=( "1.2.3.4/24" "some voodoo" )
becomes
ifconfig eth0 1.2.3.4/24
ifconfig eth0 some voodoo

We also do the same for iproute2 which has a very comples language
structure. We also do this for most of the helper programs that we use -
vlan, bridging, wireless just to name a few.

Do we want variables for every single possibility?

The beauty with the array structure is that it allows the user to define
a sequence of commands to send to a helper. The issue with the array
structure is that it is bash and we strive to support non bash shells
hence the discussion.

Oh yes, and transparently supporting the bash config where possible.

> Of course, that's still assuming the folks actually doing the baselayout2 
> work (you, and I'm not sure how many others working with you) ultimately 
> decide that it's worth the trouble to change.  I do honestly believe from 
> a user perspective it'll be easier to maintain and thus more trouble-free 
> if an individual values setup is ultimately chosen, but it's certainly 
> more work to setup from an implementation perspectiv, and very pointedly, 
> I'm not the one doing that work, so it's very easy for me to sit here and 
> get all fancy about how it "should" be done. =8^)  IOW, it's very much 
> your call.  You just asked for opinions and I'm happily giving mine. =8^)

Well, someone else will have to do that as I sure won't.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Richard Freeman]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy Marples wrote:
> One issue with that is there is no automatic way of doing that. We just
> pass the array elements onto the various programs
> 
> config_eth0=( "1.2.3.4/24" "some voodoo" )
> becomes
> ifconfig eth0 1.2.3.4/24
> ifconfig eth0 some voodoo
> 
> We also do the same for iproute2 which has a very comples language
> structure. We also do this for most of the helper programs that we use -
> vlan, bridging, wireless just to name a few.
> 
> Do we want variables for every single possibility?
> 
> The beauty with the array structure is that it allows the user to define
> a sequence of commands to send to a helper. The issue with the array
> structure is that it is bash and we strive to support non bash shells
> hence the discussion.
> 

Thanks for clarifying this - I can see the where you're coming from a
bit better in light of this explanation.  I think that as long as the
documentation is clear and well-commented we should be in good shape -
the goal is of course to make things fairly transparent to the
less-educated among us - especially when we're talking about something
simple like setting up a static IP network or DHCP.  At the same time,
if we can accomplish that while also allowing for folks using
multi-homed systems with all kinds of bridges and cost-based routing and
all that so much the better...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIqooG4/rWKZmVWkRAlo2AKCmJy98UKFngz/PuHQwbJ9X4LKsxACgo+TS
Ze5HKc9YgqvIJr9Y29gSn5E=
=WPAf
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

[gentoo-dev] Re: Re: Opinions Wanted - Arrays again :)

[Steve Long]

Roy Marples wrote:

> On Fri, 2007-10-26 at 16:36 +0000, Duncan wrote:
>> Well, several services already have a "basic" setup using named vars,
>> then something like Richard's suggested Options_eth0= as a (normally
>> commented) catch-all for anything advanced that the admin wishes to pass
>> "raw".  IMO the standard network stuff is well defined enough for that,
>> perhaps with a couple of mode-toggles and/or counters thrown in.  (A
>> counter like eth0_number_IPs= could default to one, for instance, but set
>> to something higher and with the appropriate number of address_N_eth0=
>> lines, it'd then cover your 5-address example, without having to worry
>> about figuring out how many there are, since it's a given.)
>> 
>> I think that's what many of us would like and what this subthread is
>> asking for, truth be told, but I also realize it's going to be more work
>> setting it up -- but OTOH should be simpler for the user to setup so
>> perhaps less bugs to deal with and the documentation in the net sample
>> file should be somewhat simpler as well.  The more work thing is why I've
>> not requested it before, but it'd be nice, and with others mentioning it
>> now too, now's the time to speak up if I'm going to. =8^)
> 
> Fair enough, but one of the goals of baselayout-2 is to support
> baselayout-1 configs where possible if the shell is still bash.
> 
> I'm striving to support similar configs for non bash shells so that
> there's not much of a learning curve.
> 
> Yes we could have a totally new non compatible setup, but that would
> really suck hard for upgraders yes?
> 
But baselayout knows if it's running BASH or not, right? Could you not
define a new, easy to use setup while still allowing the old syntax for
people who use BASH. (It could be an install option, with a script provided
to convert configuration, if and when the user wanted to switch.)

I must be missing something: why can this not just be mapped to a function
call?
So: config_eth0=( "1.2.3.4/24" "some voodoo" )
would become: netConfig eth0 "1.2.3.4/24" "some voodoo"
ie the spec would be: netConfig <interface> <setting1> [..<settingN>]
with a test for [ $# -gt 1 ] and then interface=$1; shift

Failing that, a plaintext config file along the lines discussed in [1] would
be cool. awk could parse it pretty quickly.

[1] http://modeemi.fi/~tuomov/b//archives/2007/01/20/T11_58_29/


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Opinions Wanted - Arrays again :)

[Natanael Copa]

On Sun, 2007-10-28 at 06:46 +0000, Steve Long wrote:

> Failing that, a plaintext config file along the lines discussed in [1] would
> be cool. awk could parse it pretty quickly.
> 
> [1] http://modeemi.fi/~tuomov/b//archives/2007/01/20/T11_58_29/

Something like Debian's /etc/network/interfaces?

http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/interfaces.5.gz

Why re-invent yet another format when there already are many out there,
well tested over years.

-nc


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Opinions Wanted - Arrays again :)

[Steve Long]

Natanael Copa wrote:
> On Sun, 2007-10-28 at 06:46 +0000, Steve Long wrote:
> 
>> Failing that, a plaintext config file along the lines discussed in [1]
>> would be cool. awk could parse it pretty quickly.
>> 
>> [1] http://modeemi.fi/~tuomov/b//archives/2007/01/20/T11_58_29/
> 
> Something like Debian's /etc/network/interfaces?
> 
> http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/interfaces.5.gz
>
Looks good to me :D Nice and simple to parse.

> Why re-invent yet another format when there already are many out there,
> well tested over years.
> 
I totally agree.
Bug me (igli) in #friendly-coders if you're on IRC and I'll help with it;
but I'm not a network guy, so someone else will have to lead the work (i'm
not that motivated basically, but it looks like an easy job-- there's
always existing code fall back on, much as it pains me to read it ;) QA
would need to be sorted too. *shrug*

I'd do the function too, though, since it matches existing configs and you'd
probably end up calling it (or a variant) in any case.

Not sure how the mapping thing would fit into it (not my bailiwick) but the
existing stuff I've seen so far can all be done with the function call. If
I'm wrong I'm sure someone will correct me (gently, I hope ;)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Alec Warner]

On 10/25/07, Roy Marples <uberlord@gentoo.org> wrote:
> Hello List
>
> It's your favourite posix shell lover here, asking for your honest
> opinions.
>
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'
> "
>
> array=("1.2.3.4 netmask 5.6.7.8;"
> "\*"
> "'host.name' netmask 1.2.3.4"
> "-I 'option; $FOO with spaces'"
> )
>
> array="'1.2.3.4 netmask 5.6.7.8;' \
> '\*' \
> \"'host.name' netmask 1.2.3.4\" \
> \"-I 'option; $FOO with spaces'\"
> "
>

Can I vote for none of the above? :)

1 > *
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 23:13 -0700, Alec Warner wrote:
> Can I vote for none of the above? :)

Sure you can - provided you come up with an alternative approach to the
problem :)

> 1 > *

Yes, that appears to be every ones thought so far.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Opinions Wanted - Arrays again :)

[Roy Marples]

On Thu, 2007-10-25 at 16:40 +0100, Roy Marples wrote:
> array="1.2.3.4 netmask 5.6.7.8;
> \*
> 'host.name' netmask 1.2.3.4
> -I 'option; $FOO with spaces'
> "

Everyone who commented has agreed that this is the most readable,
maintainable and documentable. As such I've comitted a patch for this
into baselayout's svn and will appear in baselayout-2.0.0_rc6.

I've not opted for another config format (either based on Debians or
something else) as this doesn't rock the baselayout-2 boat that much as
it's a fairly trivial patch. Once we have baselayout-2 stable then we
can think about revisiting this for future versions if there is still a
need.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Opinions Wanted - Arrays again :)

[Steve Long]

Roy Marples wrote:
> I've not opted for another config format (either based on Debians or
> something else) as this doesn't rock the baselayout-2 boat that much as
> it's a fairly trivial patch. Once we have baselayout-2 stable then we
> can think about revisiting this for future versions if there is still a
> need.
> 
Oops, missed this: ignore my other post please, list, and apologies
(although I'd be happy to help with the stuff discussed; i'll catch you on
IRC, Roy.)


-- 
gentoo-dev@gentoo.org mailing list