bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistent quote and escape handling in substitution part of param


From: Chet Ramey
Subject: Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
Date: Tue, 28 Feb 2012 17:23:58 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 2/28/12 5:18 PM, John Kearney wrote:
> On 02/28/2012 11:07 PM, Chet Ramey wrote:
>> On 2/28/12 4:28 PM, John Kearney wrote:
>>>
>>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>>> On 2/28/12 12:26 PM, John Kearney wrote:
>>>>
>>>>> But that isn't how it behaves. "${test//str/"dddd"}"
>>>>>
>>>>> because str is replaced with '"dddd"' as such it is treating
>>>>> the double quotes as string literals.
>>>>>
>>>>> however at the same time these literal double quotes
>>>>> escape/quote a single quote between them. As such they are
>>>>> treated both as literals and as quotes as such 
>>>>> inconsistently.
>>>>
>>>> I don't have a lot of time today, but I'm going to try and
>>>> answer bits and pieces of this discussion.
>>>>
>>>> Yes, bash opens a new `quoting context' (for lack of a better
>>>> term) inside ${}.  Posix used to require it, though after
>>>> lively discussion it turned into "well, we said that but it's
>>>> clearly not what we meant."
>>>>
>>>> There are a couple of places in the currently-published version
>>>> of the standard, minus any corregendia, that specify this.  The
>>>> description of ${parameter} reads, in part,
>>>>
>>>> "The matching closing brace shall be determined by counting
>>>> brace levels, skipping over enclosed quoted strings, and
>>>> command substitutions."
>>>>
>>>> The section on double quotes reads, in part:
>>>>
>>>> "Within the string of characters from an enclosed "${" to the
>>>> matching '}', an even number of unescaped double-quotes or
>>>> single-quotes, if any, shall occur."
>>>>
>>>> Chet
>>>
>>> yhea but I think the point is that the current behavior is
>>> useless. there is no case where I want a " to be printed and
>>> start a double quoted string? and thats the current behavior.
>>>
>>>
>>> Not so important how you treat it just need to pick 1. then you
>>> can at least work with it. Now you have to use a temp variable.
>>>
>>>
>>> as a side note ksh93 is pretty good, intuitive ksh93 -c
>>> 'test=teststrtest ; echo "${test//str/"dd dd"}"' testdd ddtest 
>>> ksh93 -c '( test=teststrtest ; echo ${test//str/"dd '\''dd"} )' 
>>> testdd 'ddtest
>>
>> The real question is whether or not you do quote removal on the
>> stuff inside the braces when they're enclosed in double quotes.
>> Double quotes usually inhibit quote removal.
>>
>> The Posix "solution" to this is to require quote removal if a
>> quote character (backslash, single quote, double quote) is used to
>> escape or quote another character.  Somewhere I have the reference
>> to the Austin group discussion on this.
>>
> 
> 1${A:-B}2
> 
> Logically for consistancy having double quotes at position 1 and 2
> should have no effect on how you treat string B.

Maybe, but that's not how things work in practice.  Should the following
expansions output the same thing?  What should they output?

bar=abc
echo ${foo:-'$bar'}
echo "${foo:-'$bar'}"

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]