This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: "MS-DOS style path detected" triggered by escaped $ in path


Corinna Vinschen wrote:
> On Nov 26 10:44, Adam Dinwoodie wrote:
>> If I use paths that contain $ symbols, and backslash-escape them, I start
>> seeing warnings about MS-DOS style paths in Cygwin bash.  For example, where I
>> hit <tab> after the .ssh/:
>>
>>     $ cp //pcname/C\$/cygwin/home/add/.ssh/cygwin warning:
>>       MS-DOS style path detected: //pcname/C\$/cygwin/home/add/.ssh/
>>       Preferred POSIX equivalent is: //pcname/C/$/cygwin/home/add/.ssh/
>>       CYGWIN environment variable option "nodosfilewarning" turns off this warning.
>>       Consult the user's guide for more details about POSIX paths:
>>         http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
>>
>> I believe the path I entered, //pcname/C\$/cygwin/home/add/.ssh/, is valid.
>> The equivalent MS-DOS style path would be \\pcname\C$\cygwin\home\add\.ssh\.
>>
>> This appears to simply be an erroneous warning; everything else I tried works,
>> including tab-completion, calls to cp or ls or similar.
>
> This is a bash problem, apparently.  In tcsh you'll never see this.  The
> above message is printed by Cygwin's path handling.  That means, bash
> has given the path to some POSIX function *with* the backslash included.
>
> Evaluating escape sequences is not the job of the system functions, but
> of the caller, so I'd expect that the path gets de-escaped by bash
> before calling the system function, but that's apparently not the case.

How odd.  As you say, I wouldn't expect bash to be passing the unescaped string
to any Cygwin/POSIX function.

The Windows path \\pcname\C\$ doesn't exist, so if bash were passing around the
unescaped path, I'd expect things to simply fail, whereas what I'm seeing
appears to be all the function working, just with that warning appearing as
well.  I wonder if bash is trying to be "helpful" by trying both the escaped and
unescaped versions of the string in that sort of circumstance, and using
whichever works.

I suspect the next step in working out what's going on is breaking down what's
happening in gdb to find exactly what call is triggering the warning.  I don't
think I've the time to invest in doing that right now, so a project to languish
or for someone else (whoever the bash maintainer is?) to take up.

Adam

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]