MIME-Version: 1.0
In-Reply-To: <533517069.6831891248978979849.JavaMail.root@sz0059a.emeryville.ca.mail.comcast.net>
References: <20090728091647.GK18621@calimero.vinschen.de> 	 <533517069.6831891248978979849.JavaMail.root@sz0059a.emeryville.ca.mail.comcast.net>
Date: Thu, 30 Jul 2009 14:50:10 -0400
Message-ID: <f60fe000907301150u114aecbr3b008a4380737c8@mail.gmail.com>
Subject: Re: [1.7] bash UNC path bug?
From: "Mark J. Reed" <markjreed@gmail.com>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Thu, Jul 30, 2009 at 2:36 PM, Eric Blake wrote:
>> > bash... maybe cygpath, seems to be doing something weird:
> Weird - yes.  But buggy - no.

Backtick-quoting rules are strange.  For instance, single quotes
within backticks still prevent variable expansion:

$ x=1
$ echo `echo '$x'`
$x                           # not "1"

So it's not as simple as backticks working like double quotes (within
which single quotes have no effect whatsoever):

$ echo " '$x' "
'1'

What's going on is that there's a rule that allows nesting backticks
by using successively increasing numbers of backslashes in front of
them:

`outer \`inner \\\`innermost\\\` inner\` outer`

and because of this, backticks essentially add yet another layer of
backslash parsing and removal to the mix.

This is the biggest reason to prefer new-style $(...) command
substitution to backticks.

None of this is Cygwin-specific, we just deal with literal backslashes
more in Cygwinland thanks to DOS-style file paths.


-- 
Mark J. Reed <markjreed@gmail.com>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple