[systemd-devel] [PATCH] ignore comments in multiline variable definitions

Kok, Auke-jan H auke-jan.h.kok at intel.com
Wed Feb 13 16:44:09 PST 2013


On Wed, Feb 13, 2013 at 4:26 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Wed, Feb 13, 2013 at 9:52 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
>> On Wed, Feb 13, 2013 at 08:07:07PM +0100, Lennart Poettering wrote:
>>> On Wed, 13.02.13 20:05, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>>>
>>> > Actually, the syntax already is _not_ a subset of the shell, and has its
>>> > own pecularities. Anyone trying to blindly follow shell rules is going
>>> > to be severly bitten anyway. So, why not go a bit further and change
>>> > the syntax in a way that is useful for our users?
>>>
>>> It's certainly true that we are not compatible with shell, and that we
>>> aren't even trying to be. But in this regard I see no reason to deviate.
>>>
>>> But let's take one step back. Can you make a good case why comments
>>> should trump continuation lines?
>> Status quo:
>> useful only for long lines with a hash mark in the middle.
>>
>> Proposed:
>> useful for commenting out a single line of a multi-line stanza,
>> by editing only that line, which should be less error-prone.
>>
>> Repeating the example from the original bug report:
>>
>> 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"
>>
>>    ||
>>    \/
>>
>> 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"
>>
>>> To me that doesn't even sound so
>>> useful, and it would in fact surprise me if things would work that
>>> way...
>
> We should really be careful with adding "too smart" things here. If
> the usual shell does not support this, if it really isn't something
> commonly used, we really should not add that to systemd.

this would be my main objection against supporting this. it's not
supported anywhere, and I would not want folks to start expecting this
behavior everywhere else, either.

Auke


More information about the systemd-devel mailing list