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):
C:\Temp>>cd c:/Temp > 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 >>> /c/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" >> 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" > E:\cygwin2\c\DAEMON1\anrdaemon\.profile > $ cygpath -w "/cygdrive/c/DAEMON1/anrdaemon/.profile" > C:\DAEMON1\anrdaemon\.profile Your example is okay, it perfectly illustrates the cygwin mount behavior, it's just not related to the issue. :) -- WBR, Andrey Repin (anrdae...@freemail.ru) 26.06.2011, <19:41> Sorry for my terrible english... -- 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
