Re: [PATCH] Unknown cfg function

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 28 Aug 2013 09:58:43 -0600

On 08/28/2013 09:31 AM, Tsantilas Christos wrote:
> On 08/28/2013 06:04 PM, Alex Rousskov wrote:

>> I am afraid this problem is serious enough to warrant more discussion
>> and possibly more work. It feels wrong to insist that folks do
>>
>> "foo=bar and baz"
>>
>> instead of the natural
>>
>> foo="bar and baz"
>>
>> and now may be our only chance to add proper support for that.

> So we can consider the "=" as a separator char. Probably we can support
> syntax like the followings:
> foo="bar and baz"
> foo= "bar and baz"
> foo = "bar and baz"

If we go down this route, "=" and similar characters (e.g., operators,
parenthesis/brackets, and comma) become tokens on their own. They are
not really separators because they are visible to the caller, unlike
whitespace. This is how most modern configuration and programming
languages structure their syntax.

And yes, all of your three variants above become supported automagically
then.

We can be more strict and require no whitespace around "=" (like some
old shells do for assignment), but I am not sure that we should because
it is usually best to let admin to use as little or as much whitespace
as she feels is best for the given context.

>> What do others think? Is this important enough to fix?
>>
>>
>> If we decide proper support for foo="bar and baz" syntax is important,
>> the biggest question for me is whether we should
>>
>> * change the callers to deal with three tokens (option name, equal sign,
>> and option value) or
>>
>> * change the parser to hide the quotes (producing a single complex token
>> with "=" inside but without quotes so the callers work as is)
>
> Looks that the first is the correct.
> I am seeing many problems in the second solution. Valid tokens may
> include "=", for example a url.

Indeed. Glad we agree.

I hope others weigh in on this.

Thank you,

Alex.
Received on Wed Aug 28 2013 - 15:59:00 MDT

This archive was generated by hypermail 2.2.0 : Thu Aug 29 2013 - 12:00:45 MDT