Re: [PATCホ余 Quoted values in squid.conf

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 27 May 2013 18:44:15 +1200

On 27/05/2013 4:36 a.m., Kinkie wrote:
> On Sun, May 26, 2013 at 7:29 AM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 05/25/2013 09:30 PM, Amos Jeffries wrote:
>>> On 24/05/2013 7:38 a.m., Tsantilas Christos wrote:
>>>> This patch :
>>>>
>>>> - adds support for quoted values in the entire squid.conf
>>>>
>>>> - warn about or prohibit values that can no longer be interpreted as
>>>> either quoted strings or simple tokens
>>>>
>>>> - support file:"path/to/file.name" syntax to load external configuration
>>>> files
>>>>
>>>> - support macros in "double quoted" values
>>>>
>>>> - support 'single quoted' values that do not expand macros
>>
>>> Firstly, Design simplicity:
>>>
>>> I do not believe we need to present such a wide range of potential
>>> quoting and escaping mechanisms for squid.conf. We need to pick one
>>> style which will be familiar to our administrators and ignore the other
>>> styles. Double-quoting with \-escaping of " characters for strings is
>>> very well known and the type of encoding most often requested.
>> I do not want to step on Christos' toes, but since I asked him to add
>> support for 'single quoted' strings, I feel obligated to respond to this
>> part of the review.
>>
>> While I agree that reducing the number of mechanisms is an important
>> optimization vector, the remaining mechanisms should be expressive
>> enough to form a convenient configuration language. IMO, preventing all
>> macro expansion in strings using single quotes is useful and common
>> enough (e.g., shell and Perl) to be supported along with double quoted
>> strings. I recommend but do not insist on its inclusion (until we have
>> enough user demand to back me up).
>>
>> Other opinions?
>>> IMO, we should drop the '-quoted string handling from this. It is the
>>> first step on a slipery-slope toward arbitrary quoting styles and "why
>>> not also add {-quoted strings or [-quoted strings?". Those are becoming
>>> equally popular as people become familiar with YAML/SAS/JSON syntax.
>> Single quoted strings were added not because they were popular but
>> because they offer a unique functionality -- string-global suppression
>> of macro expansion. If {-quoted string or [-quoted strings offer
>> something equality useful they should be _considered_.
> Single- and double- quotes have a well-specified meaning in shell
> scripting and some other languages (e.g. PERL). From your description,
> it seems that this behavior is implemented, so I believe there is
> benefit and no confusion from having both.

Yes they have a meaning. And yes that meaning is implemented - and then
extended a bit beyond the well-known meaning.
What I am trying to get as is do we actually need to implement them
both? I don't think so. The one which is known to allow escaping should
be sufficient.
We can extend to include the other if necessary later, but I see no need
to go quite that far yet.

Then we have the matter of that small extension which was done. To
expand %-tokens inside a quoted string.
We already have macro expansion without *any* string quoting so _at this
point_ (and I stress that it is only right now where this argument
applies) we don't *need* it in the quoting patch. We may need it later,
but that is a good argument for making it a followup patch rather than
part of this base change.
  ** the config directives using macros are perfectly fine using a
series of un-quoted tokens right now.

Amos
Received on Mon May 27 2013 - 06:44:19 MDT

This archive was generated by hypermail 2.2.0 : Mon May 27 2013 - 12:00:11 MDT