Re: [pacman-dev] Config file handling (was: [PATCH] Change -z|--showsize flag to ShowSize pacman.conf option)
On 6/1/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
Aaron and I both want to move this config file parsing to the front end; any objections to this? It will be quite a change, but we can make it much more robust while moving it. Is anyone familiar with how config file parsing is done by other programs? It seems like a very manual process currently, and a malformed config file brings pacman down. I also think we should try to continue when we encounter an unrecognized option.
What do you mean "other programs"? As in, an elegant parsing system? Or how other apps parse pacman.conf?
How other C-coded apps parse their config files in general. I don't do it often in C, so I have no idea how it is usually done. -Dan
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 6/1/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
Aaron and I both want to move this config file parsing to the front end; any objections to this? It will be quite a change, but we can make it much more robust while moving it. Is anyone familiar with how config file parsing is done by other programs? It seems like a very manual process currently, and a malformed config file brings pacman down. I also think we should try to continue when we encounter an unrecognized option.
What do you mean "other programs"? As in, an elegant parsing system? Or how other apps parse pacman.conf?
How other C-coded apps parse their config files in general. I don't do it often in C, so I have no idea how it is usually done.
Depends on the complexity of the app, but most of the time it's done manually in a similar way that we do it... that is, getline, strcmp, strcmp, strcmp, loop, done. I actually don't think our parsing is all that bad, it could just use some more info on the error case.
2007/6/1, Aaron Griffin <aaronmgriffin@gmail.com>:
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 6/1/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
Aaron and I both want to move this config file parsing to the front end; any objections to this? It will be quite a change, but we can make it much more robust while moving it. Is anyone familiar with how config file parsing is done by other programs? It seems like a very manual process currently, and a malformed config file brings pacman down. I also think we should try to continue when we encounter an unrecognized option.
What do you mean "other programs"? As in, an elegant parsing system? Or how other apps parse pacman.conf?
How other C-coded apps parse their config files in general. I don't do it often in C, so I have no idea how it is usually done.
Depends on the complexity of the app, but most of the time it's done manually in a similar way that we do it... that is, getline, strcmp, strcmp, strcmp, loop, done.
I actually don't think our parsing is all that bad, it could just use some more info on the error case.
Sorry, for my previous post in old thread. I'm reposting it here to keep track of it. ---------- Forwarded message ---------- From: Roman Kyrylych <roman.kyrylych@gmail.com> Date: 1 Чер 2007 20:32 Subject: Re: [pacman-dev] [PATCH] Change -z|--showsize flag to ShowSize pacman.conf option To: Discussion list for pacman development <pacman-dev@archlinux.org> 2007/6/1, Aaron Griffin <aaronmgriffin@gmail.com>:
On 6/1/07, Dan McGee <dpmcgee@gmail.com> wrote:
Aaron and I both want to move this config file parsing to the front end; any objections to this? It will be quite a change, but we can make it much more robust while moving it. Is anyone familiar with how config file parsing is done by other programs? It seems like a very manual process currently, and a malformed config file brings pacman down. I also think we should try to continue when we encounter an unrecognized option.
What do you mean "other programs"? As in, an elegant parsing system? Or how other apps parse pacman.conf?
I'm suggesting to use 3rd party library for parsing. I see 2 choices: 1) iniparser there is nice console app that can be used by shell scripts to parse config (made by James): http://archlinux.org/~james/projects/network/iniread-0.1/ usage example: http://archlinux.org/pipermail/arch-dev-public/2007-April/000415.html 2) libconfuse this one has nice validation features -- Roman Kyrylych (Роман Кирилич)
On 6/1/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
I'm suggesting to use 3rd party library for parsing. I see 2 choices: 1) iniparser there is nice console app that can be used by shell scripts to parse config (made by James): http://archlinux.org/~james/projects/network/iniread-0.1/ usage example: http://archlinux.org/pipermail/arch-dev-public/2007-April/000415.html
2) libconfuse this one has nice validation features
I don't really like this approach. I mean adding yet-another-dep isn't a big deal, using someone else's configuration parser means that _they_ define the format, not us. Parsing is easy. I actually used to be fairly interested in the topic, and have read quite a few books on the topic. If we do want to move to a more sophisticated parsing setup (again, I feel this isn't needed) I would be FAR more comfortable with defining our own grammer and using a standard compiler-compiler (yacc, bison, antlr, et al). This is a much MUCH superior method than using an external lib for this sort of stuff. Still, at this juncture I don't see pacman.conf as sufficiently complex enough to require a full grammar specification and all that. I mean, in all honesty, it's just the following to parse the entire file (in python): for line in pacmanconf_lines: # do some regex replacement of #.* to strip comments if line[0] == '[' and line[-1] == ']': section = line.strip('[]') continue elif line.find('=') != -1: key,value = line.split('=') # add key, value, section entry somewhere appropriate else: print "error in pacman.conf line [%s]" % line
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Roman Kyrylych