Re: [PATCH] Unknown cfg function

On 29/08/2013 3:58 a.m., Alex Rousskov wrote:
> 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"

Yes.

>> foo= "bar and baz"
>> foo = "bar and baz"

Please no.

> 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.

Eventually yes. For now just '=', '(' and ')'.

> 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.

The current no-strict configuration file does not permit whitespace. I
don't think allowing it in a more strict syntax is a good idea.

>
>>> 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.

Yes. I think the best way to do this is to have an optional extra
delimiter char passed in to NextToken. Similar to how we could
previously add '=' to the w_space tokens used by strtok().

The callers are all known and currently checking for 'foo=' explicitly.
It is not too much extra work to locate them, just to alter and test.

  It would also help with the "parameters()" syntax to be able to pass
in '(' as the extra delimiter.

Alternatively what about passing the expected token type as optional
parameter to NextToken() and handling the existence of regex, Eol, '(',
'=', or w_space based on that?

Amos
Received on Thu Aug 29 2013 - 01:30:30 MDT