[pacman-dev] [PATCH 1/1] scripts/library: add config_parser.sh

[lolilolicon]

On Fri, Sep 30, 2011 at 11:03 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Fri, Sep 30, 2011 at 7:12 AM, Dave Reisner <d at 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
>
>