Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[John Kearney]

Actually this is something that still really confuses me as well.
In the end I gave up and just did this.

                local LName="'\\''"
                echo -n "'${1//"'"/${LName}}' "


I still don't really understand why this wont work
                echo -n "'${1//"'"/"'\''"}' "
                echo -n "'${1//\'/\'\\\'\'}' "


The standard work around you see is
                echo -n \'${1//\'/\'\\\'\'}\'" "
 but its not the same thing

I guess what I don't understand is why quoting the variable affects the
substitutions string. I mean I guess I can  see how it could happen but
it does seem inconsistent, in fact it feels like a bug.

And even if it does affect it the effect seems to be weird.
i.e.

given
test="weferfds'dsfsdf"


# why does this work, this list was born of frustration, I tried
everything I could think of.
echo \'${test//"'"/\'\\\'\'}\'" "
'weferfds'\''dsfsdf'

#but none of the following
echo "'${test//'/}'"   # hangs waiting for '

echo "'${test//"'"/}'"
'weferfdsdsfsdf'

echo "'${test//"'"/"'\\''"}'"
'weferfds"'\''"dsfsdf'

echo "'${test//"'"/'\\''}'" # ahngs waiting or '

echo "'${test//"'"/\'\\'\'}'"
'weferfds\'\'\'dsfsdf'


leaving me doing something like
                local LName="'\\''"
                echo -n "'${1//"'"/${LName}}' "



I mean its a silly thing but it confuses me.


On 02/28/2012 03:47 PM, Roman Rakus wrote:
> On 02/28/2012 02:36 PM, Chet Ramey wrote:
>> On 2/28/12 4:17 AM, lhunath@lyndir.com wrote:
>>> Configuration Information [Automatically generated, do not
>>> change]: Machine: i386 OS: darwin11.2.0 Compiler:
>>> /Developer/usr/bin/clang Compilation CFLAGS:  -DPROGRAM='bash'
>>> -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin11.2.0' 
>>> -DCONF_MACHTYPE='i386-apple-darwin11.2.0'
>>> -DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale'
>>> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I.
>>> -I./include -I./lib -I/opt/local/include -pipe -O2 -arch
>>> x86_64 uname output: Darwin mbillemo.lin-k.net 11.3.0 Darwin
>>> Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; 
>>> root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 Machine Type:
>>> i386-apple-darwin11.2.0
>>> 
>>> Bash Version: 4.2 Patch Level: 20 Release Status: release
>>> 
>>> Description: The handling of backslash and quotes is completely
>>> inconsistent, counter-intuitive and in violation of how the
>>> syntax works elsewhere in bash.
>>> 
>>> ' appears to introduce a single-quoted context and \ appears
>>> to escape special characters.  That's good. A substitution
>>> pattern of ' causes bash to be unable to find the closing
>>> quote.  That's good. A substitution pattern of '' SHOULD equal
>>> an empty quoted string.  The result, however, is ''.  That's
>>> NOT good.  Suddenly the quotes are literal? A substitution
>>> pattern of '$var' SHOULD disable expansion inside the quotes.
>>> The result, however, is '[contents-of-var]'.  That's NOT good.
>>> In fact, it looks like quoting doesn't work here at all. \\ is
>>> a disabled backslash, and the syntactical backslash is removed.
>>> The result is \.  That's good. \' is a disabled single quote,
>>> but the syntactical backslash is NOT removed.  The result is
>>> \'.  That's NOT good.
>>> 
>>> It mostly looks like all the rules for handling quoting and 
>>> escaping are out the window and some random and utterly
>>> inconsistent set of rules is being applied instead.
>>> 
>>> Fix: Change parsing of the substitution pattern so that it
>>> abides by all the standard documented rules regarding quotes
>>> and escaping.
>> It would go better if you gave some examples of what you
>> consider incorrect behavior.  This description isn't helpful as
>> it stands.
>> 
> Maybe something like this:
> 
> # ttt=ggg # ggg="asd'ddd'g" # echo "'${!ttt//\'/'\''}'"
>> ^C
> # echo "'${!ttt//\'/\'\\\'\'}'" 'asd\'\\'\'ddd\'\\'\'g'
> 
> 
> 
> Anyway, I thought that single quote retains its special meaning in 
> double quotes. $ echo "'a'" 'a'
> 
> RR
>