On 2/28/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Bruce Dubbs wrote these words on 02/28/06 19:12 CST:
>
> > You have me interested. Can you give an example?
>
> Yes I can.
<snip>
>
> Notice that now the desired string was returned: "string".
Randy, I honestly believe you have tripped a bug in bash. I'm not an
expert, but here's a test case I came up with to show how the \
escapes are being handled differently in each case.
dnicholson $ echo ${BASH_VERSION}
3.00.13(1)-release
dnicholson $ N=FOO
dnicholson $ echo \\${N}
\FOO
dnicholson $ F=`echo \\${N}`
dnicholson $ echo $F
${N}
dnicholson $ F=$(echo \\${N})
dnicholson $ echo $F
\FOO
Maybe someone should submit a bug? Wait, hold the phone. This is
documented behavior. From `man bash':
When the old-style backquote form of substitution is used, backslash
retains its literal meaning except when followed by $, `, or \. The
first backquote not preceded by a backslash terminates the command sub-
stitution. When using the $(command) form, all characters between the
parentheses make up the command; none are treated specially.
So, it seems you just have to be careful when using `...` if you have
\ inside the command. All in all, seems like a good reason to use
$(...).
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page