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.
Maybe you don't, but there are several cases in the test suite that do
exactly that, derived from an old bug report.
We don't have to keep the bash-4.2 behavior, but we need to acknowledge
that it's not backwards-compatible.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
