On Fri, Sep 30, 2011 at 11:03 PM, Dan McGee <[email protected]> wrote: > On Fri, Sep 30, 2011 at 7:12 AM, Dave Reisner <[email protected]> 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 > >
