On 27/05/2013 4:36 a.m., Kinkie wrote:
On Sun, May 26, 2013 at 7:29 AM, Alex Rousskov
<[email protected]> 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
