This is the mail archive of the
mailing list for the Cygwin project.
Re: Strange cygpath behavior.
Greetings, Marco atzeri!
> On Win XP cmd.exe, is not always true that the
> two forms are equivalent (we are not anymore on CP/M, DOS age):
> The system cannot find the path specified.
This has been fixed for Vista and Win7 to my knowledge.
At least last time I ran into issue with strange CMD gehavior in this regard
and asked for checks on more recent systems, people reported that it was,
indeed, a nonissue for them.
> and if I remember correctly also somewhere else in the core of MS system
> the "\" "/" are not equivalent.
Only if application trying to be "helpful" and "sanitize" pathname according
to some self-invented standards. Core fopen() does not care.
>>> From your example:
>>> cygpath -u \\\\DAEMON1\\anrdaemon\\.profile
>>> the argument is an escaped windows network path
>>> and the outcome is the Unix equivalent
>> Not true for the "outcome" part.
>> <stdout>:cygpath -w "/c/DAEMON1/anrdaemon/.profile"
> With your cygdrive mapping /c is the disk C: so the first looks like a
> Unix path and the outcome is the equivalent windows path.
Yep, that was the idea.
> Cygpath doesn't check if the path exist
Right. But it should at least care for them being what they supposedly are.
I.e. path starting from // or \\ (or \\\\ for the sake of example) is likely a
network path, rather than a mistype.
> From my bash shell, as cygdrive is not remapped:
> $ cygpath -w "/c/DAEMON1/anrdaemon/.profile"
> $ cygpath -w "/cygdrive/c/DAEMON1/anrdaemon/.profile"
Your example is okay, it perfectly illustrates the cygwin mount behavior, it's
just not related to the issue. :)
Andrey Repin (firstname.lastname@example.org) 26.06.2011, <19:41>
Sorry for my terrible english...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple