Hi James, I am not saying I don't appreciate your work, but I am posting here to point out a few things I don't like about our old and new network scripts (more for general discussion than related to your specific efforts): A network "profile" is always only one interface. I'd expect a profile to be several interfaces that are activated all at once and are sort of tied together (I didn't read your latest version yet, did you already add such a thing?). That leads me to the second: While configuration via bash-script is easy for the programmer (you can simply parse it via 'source'), it is unsafe and becomes rather complicated when features are added. Especially when we want more than one interface in a profile, it becomes messy. I would suggest a inifile-like configuration style where each section '[foo]' marks an interface. This is much more readable to the user and allows more flexibility but itis not as easy to work with. Last but not least, invoking our netcfg tool from a GUI or any other external application is not optimal. netcfg is a shell script, but IMO should be a library. We could then have proper bindings to C/C++/python and so on. Also, when it becomes more complicated, writing bash becomes ugly very fast. I actually started a little C++ implementation of the above ideas, but got lost in bison/flex soon (anyone wanna give me a crash course on how to do it right? I have a parser that works good enough so I can start experimenting, but nothing fool-proof). I may or may not continue this work soon. The current state is this: Nothing works, I have many ideas, a highly experimental framework and hopefully some free time soon. Open for discussion :)

On 4/2/07, Aaron Griffin wrote:

...

A network "profile" is always only one interface. I'd expect a profile to be several interfaces that are activated all at once and are sort of tied together (I didn't read your latest version yet, did you already add such a thing?).

one-to-many, multi support is included.

...

That leads me to the second: While configuration via bash-script is easy for the programmer (you can simply parse it via 'source'), it is unsafe and becomes rather complicated when features are added.

I designed these so they were clear and easy to work with. Documentation needs a bit of work, but making changes anywhere is very simple. And more approachable than C. Not sure how it's 'unsafe'

...

Especially when we want more than one interface in a profile, it becomes messy.

Bash does have some nasty gotchas with scope, I'll agree there, but again, that's a matter of design. These one's are designed to work with bash not fight against it and shoehorn it into a design suitable for another language.

...

suggest a inifile-like configuration style where each section '[foo]' marks an interface. This is much more readable to the user and allows more flexibility but itis not as easy to work with.

The bash is fairly simple and readable too though.

...

Last but not least, invoking our netcfg tool from a GUI or any other external application is not optimal. netcfg is a shell script, but IMO should be a library. We could then have proper bindings to C/C++/python and so on. Also, when it becomes more complicated, writing bash becomes ugly very fast.

Is there such a demand though? Arch has always tended away from GUI tools. I'd rather not switch to a C implementation, just so we can make writing GUI's easier.

...

I actually started a little C++ implementation of the above ideas, but got lost in bison/flex soon (anyone wanna give me a crash course on how to do it right? I have a parser that works good enough so I can start experimenting, but nothing fool-proof). I may or may not continue this work soon.

And that's the state of many Arch projects. Arch has needed these scripts for *ages* and nobody else has had any interest. There is a need though, every day, there's still multiple new threads on the forums with wireless and other networking problems. And simply, the current scripts do not cater nicely towards > 1 network per interface. You can write C based scripts, but unless you knuckle down and work on them, I doubt we'll see them before the end of the year. If they do appear, they won't have reached the stage of the bash scripts before us. This is the problem we have, ideas are raised, but we don't have enough implementers.

I think getting too complex with configuration tools is not the best idea. I do, however agree that the profile-to-interface mapping should be a one-to-many mapping.

one-to-many available in these.

Also, if bash is unsafe, we need to rewrite rc.conf, makepkg, and probably a hundred other utilities. Dan and I might be willing to accept patches for a binary makepkg, so feel free.

Aye, so many of arch's scripts are written in bash. These network scripts as they're implemented, are simpler and tidier than many other things i've seen come out of Arch... However..... we could make a compromise, a halfway. If we could design a better config file, and then write a C(++) based program to parse this file and spit out requested variables, then we could have a tidier and better implementation in many aspects. We could keep the simplicity of the bash scripts, and allow the extra power of a better config file. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

On 4/2/07, Thomas Bächler wrote:

error handling: if you do something wrong, there will be no "parse error" message, but just weird things happening. And - of course - if a third party has rights to change config files, they could exploit that easily.

Depends on the error, if you miss a 'then' on an if, yeah, you'll get an error, but other things, it's not an error, just a different result :) But I know what you mean. Third party and config files is not bash specific. By nature, /etc/network.d is root writable only, although making it root only readable may be a good idea too to hide network keys.

That is great. IMO, the disadvantage here is that we need several configuration files for them .... Do you know a cool bash-parsable configuration file layout where we could put them into one file?

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.

If you say that the network scripts are nicely implemented, then I believe you and will indeed look at them more carefully tonight (I was just too tired yesterday, so I added my thoughts and didn't read the latest version of the scripts).

I hope they're nicely implemented, but i'm hardly one to judge my own code :) It does have it's faults.

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. I *could* write such a thing in python pretty quickly but I can see people not liking that. Which is fair enough. If this config file form is agreeable... i could write an interim python one and implement that until either I mess around with C or someone else writes one... ini shouldn't be difficult given it's ubiquity, so there' probably existing parsers. otherwise... any other format suggestions are welcome. Thoughts? James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2007/4/3, Thomas Bächler :

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.

Why not just use any freely available ini parsing lib? iniparser and confuse are in community -- Roman Kyrylych (Роман Кирилич)

On 4/4/07, Thomas Bächler wrote:

Roman Kyrylych schrieb:

...

Why not just use any freely available ini parsing lib? iniparser and confuse are in community

Thanks, will look at it.

http://archlinux.org/~james/projects/network/iniread-0.1/ I havn't actually written anything in C for a long time, this was based on the example and some fumbling so... criticism is welcome I guess. Depends on iniparser in community. Example usage: $ iniread /etc/network.d/someini main:ip dhcp where /etc/network.d/someini is: [main] ip = dhcp connection = wireless. ... This is implemented to a sufficient level for network script usage, though there's probably some gotchas that could be checked, and basic documentation that could be added to the program. What do you think? Implement something like this? I've got a mid semester break now, i'm eager to complete these scripts properly and finally have them see widespread use. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

On 4/4/07, Aaron Griffin wrote:

On 4/4/07, James wrote:

...

I havn't actually written anything in C for a long time, this was based on the example and some fumbling so... criticism is welcome I guess. Depends on iniparser in community.

Only point would be that returning 2 and 3 from main are sort of undefined (only 1 and 0 are standard)... I wouldn't use numbers to indicate where it failed like that, though that's personal preference... I'd just return 1 for any error.

Another think that *might* be useful depending on the lib:

- fprintf(stderr, "Cannot parse file [%s]\n", file); + fprintf(stderr, "Cannot parse file [%s]: %s\n", + file, strerror(errno));

Small thing too- we should just statically link to iniparser in the final product, in order to not make it a runtime depend. -Dan

On 4/4/07, Thomas Bächler wrote:

Dan McGee schrieb:

...

Small thing too- we should just statically link to iniparser in the final product, in order to not make it a runtime depend.

It doesn't have a shared library anyway, you can only link it statically.

Ha. Ignore me then. -Dan