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, lhun...@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 >