Recent Features
| |||||||||||||
Poettering: systemd for Administrators, Part VIIIPoettering: systemd for Administrators, Part VIIIPosted Apr 21, 2011 22:19 UTC (Thu) by dskoll (subscriber, #1630)In reply to: Poettering: systemd for Administrators, Part VIII by wahern Parent article: Poettering: systemd for Administrators, Part VIII
Sure, under the hood it could be implemented with popen/pclose just as long as it's done securely and portably. The shell command line should be hidden because it's an implementation detail.
(Log in to post comments)
Poettering: systemd for Administrators, Part VIII Posted Apr 21, 2011 22:22 UTC (Thu) by dskoll (subscriber, #1630) [Link] Following up on myself... the reason I did not do it in one of my projects is that it's handy to be able to print the file name and line number in the event of an error. So my proposed API is far too simple, but it would be nice to have some standard API that makes it convenient to iterate over multiple config.d files yet still gives you access to file name and line number for diagnostics.
Poettering: systemd for Administrators, Part VIII Posted Apr 28, 2011 1:48 UTC (Thu) by elanthis (guest, #6227) [Link]
That's just far too application specific.
Once you get into dealing with line numbers you're really dealing with the innards of your parser.
And while I'd _love_ for there to be a standard UNIX configuration file format instead of the current nightmare where every damn app uses its own format (and often a different format for different individual config files used by the same app!), that just ain't going to happen.
What you can do though is look into something like libconfig or libini or one of the dozen similar libraries and get foo.d support added there. It may not be a "standard" but it's at least a reliably available library you can depend on and use.
Poettering: systemd for Administrators, Part VIII Posted Apr 28, 2011 15:59 UTC (Thu) by dskoll (subscriber, #1630) [Link] Once you get into dealing with line numbers you're really dealing with the innards of your parser. Not at all. You really just need a way to know which file you're currently reading from. (You can keep track of line numbers on your own.) An API that didn't expose the file name would be horrible for producing diagnostics.
|
|||||||||||||