[systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
Colin Guthrie
gmane at colin.guthr.ie
Tue Nov 19 10:07:54 PST 2013
'Twas brillig, and Tom Gundersen at 19/11/13 16:57 did gyre and gimble:
> This will treat [Section:bar], [Section:foo], and [Section:baz],
> as [Section], but pass on the full section name to the options parser
> so it can treat them separately.
What is the semantics here? (I should probably know as you've likely
posted it already!)
e.g. I've seen the following semantics before for ini-style parsing:
[database]
database.adapter = pdo_mysql
database.params.host = db.dev
database.params.username = ninja
database.params.password = dressedinblack
[mydb : database]
database.params.dbname = mydatabase
This basically means the "mydb" section inherits from the "database"
section and only changes what it needs.
It seems you're using using this slightly differently in that you'll have a:
[General]
Address=xyz
and then a
[Address:xyz]
section? i.e. the instances section actually inherits from an earlier value?
If so then I doubt the semantics here can be generalised to this other
example in which case my comment is rather moot!
So take this comment with a pinch of salt :D
> @@ -253,17 +255,27 @@ static int parse_line(const char* unit,
> if (!n)
> return -ENOMEM;
>
> - if (sections && !nulstr_contains(sections, n)) {
> + e = strchr(n, ':');
> + if (e)
> + m = strndup(n, e - n);
> + else
> + m = strdup(n);
> +
> + if (sections && !nulstr_contains(sections, m)) {
Do you want to do some whitespace trimming here perhaps? e.g. if n is
"Foo :bar" or "Foo : bar" or "Foo: bar" etc.
being silently tolerant of this is probably most sensible I guess.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the systemd-devel
mailing list