[arch-dev-public] New wireless and network scripts.

[Thomas Bächler]

James schrieb:
> Arrays is the only thing I can think of,
> 
> PROFILE='multi'
> KEY[0]=something
> CONNECTION[0]='somehing else'
> 
> Or...
> 
> CONNECTION="multi"
> HOME_CONNECTION="wireless"
> HOME_KEY="sdasdsa"
> WORK_CONNECTION="ethernet"
> WORK_IP="dsaomdsadas"
> NETWORKS=(HOME WORK)
> 
> Or.......... my dream setup, ala bsd
> 
> home="connection wireless key 12346 interface ipw0"
> main="connection multi childs home,work "
> 
> but it's very nasty to parse -- not impossible though, I have done it
> in experiments -- and involves wrapping all of the iwconfig and
> ifconfig options to acheive an equivalent functionality level.
> wrapping that many is icky.

Another idea, completely using bash-style:

INTERFACES=('if1' 'if2' 'if3')

profile_if1() {
  [options for if1]
}

profile_if2() {
  [options for if2]
}

profile_if3() {
  [options for if3]
}

Then source the file, and 'eval profile_$i', then set up the interface.
But it would be more difficult for the average user.

>> That would be worth looking into.
> 
> Further thoughts, and implementation idea:
> I thought about an ini style config. That could work *really* well.
> I don't want to drop the bash side of these either, it'll be too long
> before we see something new, and these work well, I havn't picked up
> any new bugs for a few days now... not to say they don't exist.
> 
> So... a Csomething based parser of ini files. Would be totally awesome.
> [main]
> connection=wireless
> key=something
> security=super
> 
> Orr.... another file....
> ------
> [main]
> connection=multi
> profiles=home something else
> [home]
> connection=wireless
> [something]
> connection=ethernet
> -------
> .... and you get the idea.
> 
> If I could run: netini main.connection and get the value from the ini
> file, I'll rewrite these netscripts in a night and they will work far
> better, and the codebase will be far better.

As I said, I have a partially working parser in flex/bison, but I don't
think I did it right. It may be a good idea, though I would suggest this
format:

generaloption1=foobar
dns="1.2.3.4 5.6.7.8"

[interface1]
someoptions=somevalue
otheroption="other value"

[interface2]
moreoptions="more values"

We could parse it like that: calling 'netini profilename' would return

generaloption1=foobar
dns="1.2.3.4 5.6.7.8"
INTERFACE_LIST=('interface1' 'interface2')

Later you would call 'netini profilename interface1' which would return
the options for interface1. You could eval those in the scripts. I think
 this would make a very readable configuration. And the parser is
definitely possible in C or C++ easily, if you worked with bison before.
If someone will give me a crash course on how to do that right, I could
take care of that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20070403/9eb4c153/attachment.pgp>