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.