[systemd-devel] [PATCH] Correctly parse commented multiline variables
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Tue Feb 5 12:17:11 PST 2013
On Mon, Feb 04, 2013 at 01:53:24PM +0100, Michal Vyskocil wrote:
> > Hi,
> > can you check if it works with the following test case?
> > For me it doesn't, and I think there must be a bug.
> >
> > Zbyszek
>
> Hi Zbigniew,
>
> sorry for a responding on my initial email, but for some reason your
> response[1] did not appear in my mailbox. Anyway your test have raised
> an interesting problem - the load_env_file does not parse a variable
> definition like shell* do. It considers everything behind quotes as a
> variable content and continuation character does not matter.
>
> FOO="this
>
> is
> #commented
>
> multiline
> variable"
>
> will be properly recognized by shell, but not by systemd. On the other
> hand, it will accept definitions like FOO=one two, which has a different
> meaning in a shell, so must be quoted. Therefor we shall define
> systemd's behavior and of course how much close systemd should mimic
> shell.
Hi,
I agree we should define behaviour that is convenient for our use case,
and we should follow existing behaviour in shells, unless there's a
reason not to. Or at least that is how I understood you.
> I'd say systemd can ignore quoting and be a bit stricter than a
> shell, so accepts only lines ends on "\\\n" as a continuation and in
+1
> this mode accept #comments to be a part of a definition
>
> FOO=this \
> is \
> #commented \
> multiline \
> variable
-0
I'm not sure. Actually, I think that using '#' in strings in unit files
is a relatively rare. OTOH, one would quite often want to comment out
just one line from a multiline definition, e.g. just one option out of
a bunch. So I think that accepting '#' to ignore a line should work
always, event after "\\\n".
Even looking at one of the examples:
SPAMD_ARGS="--socketpath=/var/lib/bulwark/spamd \
--nouser-config \
--virtual-config-dir=/var/lib/bulwark/domains/%l/%d \
--siteconfigpath=/var/lib/bulwark/config \
--username=bulwark \
--max-children=25 \
--timeout-child=600"
I can easy imagine wanting to replace it with:
SPAMD_ARGS="--socketpath=/var/lib/bulwark/spamd \
--nouser-config \
--virtual-config-dir=/var/lib/bulwark/domains/%l/%d \
--siteconfigpath=/var/lib/bulwark/config \
#--username=bulwark \
--username=myusername \
--max-children=25 \
--timeout-child=600"
> The question is what to do with a definitions ends on a \, followed by
> comment
>
> FOO=this \
> #is commented
If we accept the interpration that '#' always works, then this would
become equivalent to
FOO=this \
<EOF>
i.e. the backslash would be basically ignored.
Zbyszek
> will result in "this #is commented", but this is probably not what
> people will expect and it behaves differently than a shell. We might
> have a rule definition can't end on a comment, even this sounds a bit
> nasty to me.
>
> This is probably the reason, where shell syntax make it clear
> FOO="this \
> #is commented"
>
> *I've no idea if there are any differences in variable definitions, but
> I use dash as the reference one. So just s/shell/dash/
>
> [1] http://lists.freedesktop.org/archives/systemd-devel/2013-February/008566.html
>
> Regards
> Michal Vyskocil
>
> On Fri, Feb 01, 2013 at 02:47:24PM +0100, Michal Vyskocil wrote:
> > Buffer c must be freeed when code detects a comment or empty string after
> > a strip. Otherwise no other variable definitions will be loaded.
> [snip]
More information about the systemd-devel
mailing list