[Top][All Lists]

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

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

From: John Kearney
Subject: Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
Date: Tue, 28 Feb 2012 23:23:37 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120129 Thunderbird/10.0

On 02/28/2012 11:15 PM, Chet Ramey wrote:
> On 2/28/12 5:07 PM, Chet Ramey wrote:
>>> 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.
> http://austingroupbugs.net/view.php?id=221
> Chet

This however doesn't make reference to changing that behavior if you
enclose the entire thing in double quotes.

${a//a/"a"} should behave the same as "${a//a/"a"}"

I mean the search and replace should behave the same. Currently they dont

reply via email to

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