'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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel