On Fri, Sep 30, 2011 at 11:03 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Sep 30, 2011 at 7:12 AM, Dave Reisner <d@falconindy.com> wrote:
At the risk of painting my shed green, I dislike your naming convention, particularly conf_key_set, which doesn't set anything at all. I would have thought that something such as the following would be appropriate:
# accessors conf_key_isset() # determines existance of a key w/o an associated value. conf_keyval_get() # gets the value of a key. These are pacman.conf only, right? Why not pacman_conf_get() pacman_conf_isset()
No they're pretty simple and general. But we should create pacman_conf_* functions that call these more general functions.
Another set of issues that may/may not be covered, but I didn't see anything at first glance: 1) is this [options] only, or are sections not even handled? Big problem if this is to be made universal, or one is looking up SigLevel... I think one needs to call this with both a file path and a section name. We probably also need a function that returns all the section names (pacman_conf_get_sections?).
I considered this- indeed, this is a reason I opted for reading from stdin, think something like this: pacman_conf_get_section $header | conf_key_val $key
2) How are multivalued options handled? Remembering the following are equivalent: HoldPkg = foo1 foo2 HoldPkg = foo3 and HoldPkg = foo1 foo2 foo3
These are not handled yet. We can write something like: conf_key_get_vals $key [$delim [$def]] ...just a variant of conf_key_val()
# mutators conf_key_set() # sets a key without a value, as long as it doesn't exist. conf_keyval_set() # sets a key with a value, as long as it doesn't exist.
And of course, accessors return 0/1 to indicate existance, mutators return 0/1 to indicate write success/failure. If we start mutating the config file, I'll be a bit scared- I don't see a whole lot of need for these anytime soon.
-Dan