Re: cygpath 3.3.4 : incorrect windows to unix path conversions
Hello, Thank you for the information, this helped me formulate a solution. Best, - TTimo On Tue, Jun 28, 2022 at 10:20 AM Andrey Repin wrote: > Greetings, Timothee Besset! > > > Hello, > > > We are seeing some odd behavior from cygpath.exe when it is copied and > used > > outside the normal cygwin installation directory: > > > PS C:\Users\ttimo> C:\cygwin64\bin\cygpath.exe -a -u "C:" > > /cygdrive/c > > To begin with, "C:" means "current working directory on drive 'C:'". Not > "root > directory of 'C:'". > The behavior of cygpath is incorrect in this case. > > > After copying cygpath.exe and cygwin1.dll to a blank C:\tmp: > > Both must be in '…/bin' directory, this is user error. > > > PS C:\Users\ttimo> C:\tmp\cygpath.exe -a -u "C:" > > / > > > (should be /cygdrive/c!) > > No? See above. > > > After copying those same files to C:\tmp\tmp: > > > PS C:\Users\ttimo> C:\tmp\tmp\cygpath.exe -a -u "C:" > > /cygdrive/c > > > It works again! > > By coincidence. (And no.) > > > We bundle a few cygwin pieces (ssh, rsync) in our application and run > them > > on machines that may not have cygwin installed, this is why we are trying > > to use cygpath outside a normal installation directory - see > > https://gitlab.steamos.cloud/devkit/steamos-devkit for details. > > See above, cygwin tools' layout must follow FHS, or you will see all sorts > of > issues. > That aside, you could always use /proc/cygdrive/ root for manual path > conversion. > > > We've been using this setup for more than a year and only noticing this > > now; I suspect this used to work fine but I couldn't tell you of an older > > version that worked for sure. > > Um, no. > > > -- > With best regards, > Andrey Repin > Tuesday, June 28, 2022 11:14:52 > > Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath 3.3.4 : incorrect windows to unix path conversions
On Tue, Jun 28, 2022 at 1:46 AM Timothee Besset wrote: > > Hello, > > We are seeing some odd behavior from cygpath.exe when it is copied and used > outside the normal cygwin installation directory: > Don't do this if you just need to convert Linux style file paths to windows file paths. Use the cygpath.exe from MSYS2 by installing it and adding its bin directory to your windows path. This does not require the cygwin1.dll, and is designed to interoperate well with windows. If you need to interact with the cygwin environment from powershell, start powershell from the bash prompt so PS is embedded in the cygwin environment. Then all the mounts expected by cygwin programs are established, so when you run cygwin programs from PS, they run in the env they expect. HTH Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath 3.3.4 : incorrect windows to unix path conversions
On Tue, 28 Jun 2022 09:44:56 +0200 Timothee Besset wrote: > We are seeing some odd behavior from cygpath.exe when it is copied and used > outside the normal cygwin installation directory: > > PS C:\Users\ttimo> C:\cygwin64\bin\cygpath.exe -a -u "C:" > /cygdrive/c > > After copying cygpath.exe and cygwin1.dll to a blank C:\tmp: > > PS C:\Users\ttimo> C:\tmp\cygpath.exe -a -u "C:" > / > > (should be /cygdrive/c!) Both / and /cygdrive/c are correct in this case. The root directory for cygwin is the parent directory of the directory where cygwin1.dll is located. If cygwin1.dll is located in c:\tmp, the root directory for cygwin is c:\. Therefore, / is correct answer for cygpath -u 'c:\'. This is the same with the fact that c:\cygwin64\bin\cygpath.exe -u "c:\cygwin64" returns / rather than /cygdrive/c/cygwin64. > After copying those same files to C:\tmp\tmp: > > PS C:\Users\ttimo> C:\tmp\tmp\cygpath.exe -a -u "C:" > /cygdrive/c In this case, the root directory for cygwin is c:\tmp. Therefore, c:\ is outside of the cygwin directories. So, cygpath -u 'c:\' returns /cygdrive/c. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath 3.3.4 : incorrect windows to unix path conversions
Greetings, Timothee Besset! > Hello, > We are seeing some odd behavior from cygpath.exe when it is copied and used > outside the normal cygwin installation directory: > PS C:\Users\ttimo> C:\cygwin64\bin\cygpath.exe -a -u "C:" > /cygdrive/c To begin with, "C:" means "current working directory on drive 'C:'". Not "root directory of 'C:'". The behavior of cygpath is incorrect in this case. > After copying cygpath.exe and cygwin1.dll to a blank C:\tmp: Both must be in '…/bin' directory, this is user error. > PS C:\Users\ttimo> C:\tmp\cygpath.exe -a -u "C:" > / > (should be /cygdrive/c!) No? See above. > After copying those same files to C:\tmp\tmp: > PS C:\Users\ttimo> C:\tmp\tmp\cygpath.exe -a -u "C:" > /cygdrive/c > It works again! By coincidence. (And no.) > We bundle a few cygwin pieces (ssh, rsync) in our application and run them > on machines that may not have cygwin installed, this is why we are trying > to use cygpath outside a normal installation directory - see > https://gitlab.steamos.cloud/devkit/steamos-devkit for details. See above, cygwin tools' layout must follow FHS, or you will see all sorts of issues. That aside, you could always use /proc/cygdrive/ root for manual path conversion. > We've been using this setup for more than a year and only noticing this > now; I suspect this used to work fine but I couldn't tell you of an older > version that worked for sure. Um, no. -- With best regards, Andrey Repin Tuesday, June 28, 2022 11:14:52 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath gives no output, cygwin 3.3.4
Il giorno mer 11 mag 2022 alle ore 09:54 Daniel Krumlinde Lundvall via Cygwin ha scritto: > So far everything seems o be working except for cygpath, which gives us no > ouput. > > I had a similar problem and the real problem was SentinelOne that broke cygpath and other binaries. Did you try disabling your antivirus? Antonio Petrelli -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
On 08.02.2022 17:04, Antonio Petrelli wrote: Il giorno mar 8 feb 2022 alle ore 15:57 Ken Brown ha scritto: I suspect that SentinelOne is interfering with Cygwin (see https://cygwin.com/faq/faq.html#faq.using.bloda). Can you disable it or at least exclude the Cygwin directory from whatever it does? No I can't, at least not immediately, it's controlled by the corporate. I think that SentinelOne can be safely put in the list of interfering software :-( Thanks anyway Antonio as your corporate is paying for it, you can probably open a ticket and complain about the behaviour Maybe they will learn something... Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
Il giorno mar 8 feb 2022 alle ore 15:57 Ken Brown ha scritto: > On 2/8/2022 9:37 AM, Antonio Petrelli wrote: > > Il giorno mar 8 feb 2022 alle ore 15:30 marco atzeri < > marco.atz...@gmail.com> > > ha scritto: > >> check if strace give some hints > >> > >>strace -o /tmp/strace.txt /usr/bin/cygpath --help > >> > > > > The result is here: > > https://pastebin.com/n56RTAiu > > This looks suspicious: > > Process 2480 loaded C:\Program Files\SentinelOne\Sentinel Agent > 21.7.4.1043\InProcessClient64.dll at 7ffb7c94 > > I suspect that SentinelOne is interfering with Cygwin (see > https://cygwin.com/faq/faq.html#faq.using.bloda). Can you disable it or > at > least exclude the Cygwin directory from whatever it does? > No I can't, at least not immediately, it's controlled by the corporate. I think that SentinelOne can be safely put in the list of interfering software :-( Thanks anyway Antonio -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
On 2/8/2022 9:37 AM, Antonio Petrelli wrote: Il giorno mar 8 feb 2022 alle ore 15:30 marco atzeri ha scritto: check if strace give some hints strace -o /tmp/strace.txt /usr/bin/cygpath --help The result is here: https://pastebin.com/n56RTAiu This looks suspicious: Process 2480 loaded C:\Program Files\SentinelOne\Sentinel Agent 21.7.4.1043\InProcessClient64.dll at 7ffb7c94 I suspect that SentinelOne is interfering with Cygwin (see https://cygwin.com/faq/faq.html#faq.using.bloda). Can you disable it or at least exclude the Cygwin directory from whatever it does? Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
Il giorno mar 8 feb 2022 alle ore 15:30 marco atzeri ha scritto: > On Tue, Feb 8, 2022 at 3:24 PM Antonio Petrelli wrote: > > > > Il giorno mar 8 feb 2022 alle ore 15:19 marco atzeri ha scritto: > >> > >> > > > I just installed cygwin on my Windows 10 laptop. > >> > > > I need to use the cygpath utility and it simply does not do > anything, > >> > > even > >> > > > cygpath --help > >> > > > does anything. > >> > > > >> > > > What should I do? > >> > > > >> > > Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. > >> > > > >> > > >> > It's there AFAIK, I see it in the C:\cygwin64\bin directory. Is that > right? > >> > >> check that is the last version > >> > >> ls -l /usr/bin/cygwin1.dll > >> -rwxr-xr-x 1 matzeri Domain Users 3554998 Jan 31 20:37 > /usr/bin/cygwin1.dll > >> > >> if you updated with a process still running it maybe not the last one > > > > > > This is what I see: > > -rwxr-xr-x 1 MYCOMPANY+Antonio_Petrelli MYCOMPANY+Antonio_Petrelli > 3554998 Jan 31 19:37 /usr/bin/cygwin1.dll > > > > So it seems it is OK (notice that I am at UTC+1). > > check if strace give some hints > > strace -o /tmp/strace.txt /usr/bin/cygpath --help > The result is here: https://pastebin.com/n56RTAiu Notice that it caused a Segmentation fault, though. Antonio -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
On Tue, Feb 8, 2022 at 3:24 PM Antonio Petrelli wrote: > > Il giorno mar 8 feb 2022 alle ore 15:19 marco atzeri ha scritto: >> >> > > > I just installed cygwin on my Windows 10 laptop. >> > > > I need to use the cygpath utility and it simply does not do anything, >> > > even >> > > > cygpath --help >> > > > does anything. >> > > >> > > > What should I do? >> > > >> > > Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. >> > > >> > >> > It's there AFAIK, I see it in the C:\cygwin64\bin directory. Is that right? >> >> check that is the last version >> >> ls -l /usr/bin/cygwin1.dll >> -rwxr-xr-x 1 matzeri Domain Users 3554998 Jan 31 20:37 /usr/bin/cygwin1.dll >> >> if you updated with a process still running it maybe not the last one > > > This is what I see: > -rwxr-xr-x 1 MYCOMPANY+Antonio_Petrelli MYCOMPANY+Antonio_Petrelli 3554998 > Jan 31 19:37 /usr/bin/cygwin1.dll > > So it seems it is OK (notice that I am at UTC+1). it seems so > > Antonio check if strace give some hints strace -o /tmp/strace.txt /usr/bin/cygpath --help -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
Il giorno mar 8 feb 2022 alle ore 15:19 marco atzeri ha scritto: > > > > I just installed cygwin on my Windows 10 laptop. > > > > I need to use the cygpath utility and it simply does not do anything, > > > even > > > > cygpath --help > > > > does anything. > > > > > > > What should I do? > > > > > > Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. > > > > > > > It's there AFAIK, I see it in the C:\cygwin64\bin directory. Is that > right? > > check that is the last version > > ls -l /usr/bin/cygwin1.dll > -rwxr-xr-x 1 matzeri Domain Users 3554998 Jan 31 20:37 /usr/bin/cygwin1.dll > > if you updated with a process still running it maybe not the last one > This is what I see: -rwxr-xr-x 1 MYCOMPANY+Antonio_Petrelli MYCOMPANY+Antonio_Petrelli 3554998 Jan 31 19:37 /usr/bin/cygwin1.dll So it seems it is OK (notice that I am at UTC+1). Antonio -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
On Tue, Feb 8, 2022 at 3:06 PM Antonio Petrelli wrote: > > Il giorno mar 8 feb 2022 alle ore 13:35 Andrey Repin > ha scritto: > > > > I just installed cygwin on my Windows 10 laptop. > > > I need to use the cygpath utility and it simply does not do anything, > > even > > > cygpath --help > > > does anything. > > > > > What should I do? > > > > Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. > > > > It's there AFAIK, I see it in the C:\cygwin64\bin directory. Is that right? > > Thanks > Antonio check that is the last version ls -l /usr/bin/cygwin1.dll -rwxr-xr-x 1 matzeri Domain Users 3554998 Jan 31 20:37 /usr/bin/cygwin1.dll if you updated with a process still running it maybe not the last one -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
Il giorno mar 8 feb 2022 alle ore 13:35 Andrey Repin ha scritto: > > I just installed cygwin on my Windows 10 laptop. > > I need to use the cygpath utility and it simply does not do anything, > even > > cygpath --help > > does anything. > > > What should I do? > > Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. > It's there AFAIK, I see it in the C:\cygwin64\bin directory. Is that right? Thanks Antonio -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath not doing anything on a fresh install
Greetings, Antonio Petrelli! > Hello > I just installed cygwin on my Windows 10 laptop. > I need to use the cygpath utility and it simply does not do anything, even > cygpath --help > does anything. > What should I do? Make sure cygwin1.dll is there. Some "antivirus" may have eaten it. -- With best regards, Andrey Repin Tuesday, February 8, 2022 15:28:32 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath and star character
On Jul 14 15:26, Ken Brown via Cygwin wrote: > On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote: > > Hi > > > > I found a strange behaviour of the program cygpath program > > > > 0 >cygpath -w "./*/*" <--- IMHO wrong output > > \ > > > > 0 >cygpath -w "./*/*" | od -a <--- a detailed dump > > 000 o nul * \ o nul * nl > > 010 > > What you're seeing here is a consequence of the way Cygwin handles valid > POSIX file names that contain characters (like '*') that are not allowed in > Windows file names. See "Forbidden characters in filenames" at > > https://cygwin.com/cygwin-ug-net/using-specialnames.html > > Internally, Cygwin converts "./*/*" to the wide char string L"*\*" with '*' > replaced by 0xf02a. This then gets converted to the multibyte sequence in > your "detailed dump", which is not quite detailed enough: > > $ cygpath -w "./*/*" | od -b > 000 357 200 252 134 357 200 252 012 > 010 > > I tend to agree that this is not desirable behavior. I doubt if users of > 'cygpath -w' expect to get a result that contains transformed forbidden > characters. But maybe there's a use case for this that I'm missing. > Corinna? The purpose of cygpath is to convert paths between Cygwin and Windows, so that you can access the same file in both worlds. The '*' character is a valid character in Cygwin, but the created file will have a unicode 0xf02a in its place. If cygpath doesn't convert the path accordingly, accessing the file from Windows via the converted path would fail. > > 0 >cygpath -wp "./*/*" <-- but this works as expected > > *\* > > > > Is this bug or expected behavior ? > > It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give different > results on a path that doesn't contain a colon. Yeah, that's not quite right. Historically, the conversion of path lists is performed on multibyte paths, not on wide char paths. This has never been changed, and that results in special characters getting lost. So in fact, the behaviour in -p is wrong for those chars invalid in Windows and only valid for POSIX paths. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath and star character
On 15/07/2021 00:07, Tomas Jura via Cygwin wrote:
Hi
My use case is building the CLASSPATH environment variable for java.
Like:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory/*' )"
CLASSPATH can contain the star character at the end on Windows.
Example C:\Apps\java\lib\* , which means something different then just
C:\Apps\java\lib, ie. the star is necessary there.
Tomas
So do:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory')\*"
If you pass the asterisk to cygpath it will naturally consider it to be
a character in a pathname and give you the equivalent Windows path that
Cygwin would construct using the open() syscall. This is cygpath's
purpose, after all!
--
Sam Edge
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath and star character
Hi
My use case is building the CLASSPATH environment variable for java. Like:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory/*' )"
CLASSPATH can contain the star character at the end on Windows. Example
C:\Apps\java\lib\* , which means something different then just
C:\Apps\java\lib, ie. the star is necessary there.
Tomas
14. 07. 21 v 21:26 Ken Brown wrote:
On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote:
Hi
I found a strange behaviour of the program cygpath program
0 >cygpath -w "./*/*" <--- IMHO wrong output
\
0 >cygpath -w "./*/*" | od -a <--- a detailed dump
000 o nul * \ o nul * nl
010
What you're seeing here is a consequence of the way Cygwin handles
valid POSIX file names that contain characters (like '*') that are not
allowed in Windows file names. See "Forbidden characters in
filenames" at
https://cygwin.com/cygwin-ug-net/using-specialnames.html
Internally, Cygwin converts "./*/*" to the wide char string L"*\*"
with '*' replaced by 0xf02a. This then gets converted to the
multibyte sequence in your "detailed dump", which is not quite
detailed enough:
$ cygpath -w "./*/*" | od -b
000 357 200 252 134 357 200 252 012
010
I tend to agree that this is not desirable behavior. I doubt if users
of 'cygpath -w' expect to get a result that contains transformed
forbidden characters. But maybe there's a use case for this that I'm
missing. Corinna?
0 >cygpath -wp "./*/*" <-- but this works as expected
*\*
Is this bug or expected behavior ?
It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give
different results on a path that doesn't contain a colon.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath and star character
On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote: Hi I found a strange behaviour of the program cygpath program 0 >cygpath -w "./*/*" <--- IMHO wrong output \ 0 >cygpath -w "./*/*" | od -a <--- a detailed dump 000 o nul * \ o nul * nl 010 What you're seeing here is a consequence of the way Cygwin handles valid POSIX file names that contain characters (like '*') that are not allowed in Windows file names. See "Forbidden characters in filenames" at https://cygwin.com/cygwin-ug-net/using-specialnames.html Internally, Cygwin converts "./*/*" to the wide char string L"*\*" with '*' replaced by 0xf02a. This then gets converted to the multibyte sequence in your "detailed dump", which is not quite detailed enough: $ cygpath -w "./*/*" | od -b 000 357 200 252 134 357 200 252 012 010 I tend to agree that this is not desirable behavior. I doubt if users of 'cygpath -w' expect to get a result that contains transformed forbidden characters. But maybe there's a use case for this that I'm missing. Corinna? 0 >cygpath -wp "./*/*" <-- but this works as expected *\* Is this bug or expected behavior ? It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give different results on a path that doesn't contain a colon. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -w space becomes line breaks?
Greetings, 斟酌鵬兄! Please no top-posting in the list. > On Sun, Nov 1, 2020 at 11:39 PM Achim Gratz wrote: >> >> > Is this intended or am I misconfiguring something? >> >> You have to quote any arguments that may contain spaces in the shell, >> else they get parsed as separate words and later interpreted as separate >> arguments to cygpath. > Ooooh thanks I do it like cygpath -w "`pwd`" and now it works now. There's an easier way to achieve the same without a subshell call. cygpath -alw . -- With best regards, Andrey Repin Sunday, November 1, 2020 23:50:08 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -w space becomes line breaks?
Ooooh thanks I do it like cygpath -w "`pwd`" and now it works now. On Sun, Nov 1, 2020 at 11:39 PM Achim Gratz wrote: > > > Is this intended or am I misconfiguring something? > > You have to quote any arguments that may contain spaces in the shell, > else they get parsed as separate words and later interpreted as separate > arguments to cygpath. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Samples for the Waldorf Blofeld: > http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Regards, Penguin -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -w space becomes line breaks?
> Is this intended or am I misconfiguring something? You have to quote any arguments that may contain spaces in the shell, else they get parsed as separate words and later interpreted as separate arguments to cygpath. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -u converts quoted UNC paths to local
Greetings, Corinna Vinschen! > On Apr 3 19:20, Andrey Repin wrote: >> Greetings, All! >> >> This can be considered "working by design", but it really imposes some >> serious >> restrictions on interoperability with Cygwin, that I think can be avoided. >> >> ... >> >> After some further testing, this seems to be affecting IP-based UNC paths >> only. >> >> The essence is this: >> >> $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" >> 26.10.2018 18:16 431 online.sh >> >> $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh >> //192.168.1.5/wwwroot/ccenter/bin/online.sh >> >> $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" >> /192.168.1.5/wwwroot/ccenter/bin/online.sh > This shows that it's not cygpath. It's the quoting, thus the shell > mangles the path. Oh, sorry, stupid habit of mine. Yes, in Windows convention, shell (CMD) does not perform unquoting. This makes it impossible to reliable pass parameters to cygpath. -- With best regards, Andrey Repin Thursday, April 4, 2019 10:48:12 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
Re: cygpath -u converts quoted UNC paths to local
On 2019-04-03 12:20 pm, Andrey Repin wrote: Greetings, All! This can be considered "working by design", but it really imposes some serious restrictions on interoperability with Cygwin, that I think can be avoided. ... After some further testing, this seems to be affecting IP-based UNC paths only. The essence is this: $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" 26.10.2018 18:16 431 online.sh $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" /192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u \\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh" //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ Using echo is a good way of checking just what the shell is handing to your program. But I totally agree that this is a major interoperability annoyance. I'm using Bash 4.4.12(3): $ echo \\192.168.1.5\wwwroot\ccenter\bin\online.sh \192.168.1.5wwwrootccenterbinonline.sh $ echo "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" \192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo '\\192.168.1.5\wwwroot\ccenter\bin\online.sh' \\192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo \\foo\wwwroot\ccenter\bin\online.sh \foowwwrootccenterbinonline.sh $ echo "\\foo\wwwroot\ccenter\bin\online.sh" \foo\wwwroot\ccenter\bin\online.sh $ echo '\\foo\wwwroot\ccenter\bin\online.sh' \\foo\wwwroot\ccenter\bin\online.sh read -r is an alternate way of getting text into a command line that might otherwise turn into quoting hell. $ read -r; cygpath -u $REPLY \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh -- 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
RE: EXT: Re: cygpath -u converts quoted UNC paths to local
Not completely the shell. From a Windows command prompt: c:\Apps\cygwin64\bin\cygpath.exe -u \\123.456.789.321\wwwroot\ccenter\bin\online.sh //123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "\\123.456.789.321\wwwroot\ccenter\bin\online.sh" /cygdrive/c/123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "\\\123.456.789.321\wwwroot\ccenter\bin\online.sh" //123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "123.456.789.321\wwwroot\ccenter\bin\online.sh" //123.456.789.321/wwwroot/ccenter/bin/online.sh Looks like cygpath is doing something different when the argument is enclosed in quotes (same behavior if single-quote ' is used). > -Original Message- > From: cygwin-ow...@cygwin.com On Behalf > Of Achim Gratz > Sent: Wednesday, April 03, 2019 1:12 PM > To: cygwin@cygwin.com > Subject: EXT: Re: cygpath -u converts quoted UNC paths to local > > Andrey Repin writes: > > This can be considered "working by design", but it really imposes some > > serious restrictions on interoperability with Cygwin, that I think can be > avoided. > > But cygpath never sees the quotes, so whatever is done to the path that it > gets is actually the work of your shell. In other words, you need to shell- > quote the backslashes as appropriate for your shell. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk > Blofeld]>+ > > DIY Stuff: > http://Synth.Stromeko.net/DIY.html > > -- > 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 -- 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
Re: cygpath -u converts quoted UNC paths to local
Andrey Repin writes: > This can be considered "working by design", but it really imposes some serious > restrictions on interoperability with Cygwin, that I think can be avoided. But cygpath never sees the quotes, so whatever is done to the path that it gets is actually the work of your shell. In other words, you need to shell-quote the backslashes as appropriate for your shell. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- 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
Re: cygpath -u converts quoted UNC paths to local
On Apr 3 19:20, Andrey Repin wrote: > Greetings, All! > > This can be considered "working by design", but it really imposes some serious > restrictions on interoperability with Cygwin, that I think can be avoided. > > ... > > After some further testing, this seems to be affecting IP-based UNC paths > only. > > The essence is this: > > $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" > 26.10.2018 18:16 431 online.sh > > $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh > //192.168.1.5/wwwroot/ccenter/bin/online.sh > > $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" > /192.168.1.5/wwwroot/ccenter/bin/online.sh This shows that it's not cygpath. It's the quoting, thus the shell mangles the path. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
RE: cygpath compatiblity break (v2.1 -> v2.7)
From: Chevallier Yves > ... > So two questions in this thread: > 1. How can I participate to the thread and use this mailing list properly? > ... > From: Brian Inglis > ... > Looks like the 207653 comes from the Return-Path header when > you view the raw message content. The answer was in the message that you quoted, where, in that case, the message ID was 207653. --Ken Nellis -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 10/05/2017 14:35, Chevallier Yves wrote: I don't want to suscribe to it, I just want to be able to post and reply not more. Or you subscribe or you use a NNTP gateway. https://cygwin.com/news.html There are no other way. There is no issue tracker for Cygwin. This is not very convenient. We track the problems on the mailing list. Internet is full of issue trackers with no enough resource to follow up and solve them. In your case as current cygwin version does not show the problem, it is for me solved. Regards Marco -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
I don't understand your points. See my reply below with the leading char $ 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: cygpath compatiblity break (v2.1 -> v2.7) . From: Marco Atzeri . To: cygwin at cygwin dot com . Date: Wed, 10 May 2017 11:29:32 +0200 . Subject: Re: cygpath compatiblity break (v2.1 -> v2.7) . Authentication-results: sourceware.org; auth=none . References: <2ebc717eaaf041d7b516e93a6123b...@de01ex22.global.jhcn.net> <2b3a4976-09b2-cece-759d-0b2379ae3...@gmail.com> On 10/05/2017 11:12, Chevallier Yves wrote: Unfortunately I haven't tried 2.8 because we've already validated 2.7 internally and I would need at least 3 months to access to 2.8. That said I searched for a release note with information about cygpath, but I haven't find any. Bottom Post in this mailing list. Please. $ Is this a question? What do you please me for? Cygpath is part of the cygwin package. The source specific of "cygpath" is unchanged by ~ 6 months. The issue you see was likely a change inside the cygwin dll. $ Yes it is exactly what I was arguing because even if I change `cygpath.exe` for the oldest version, the issue is still the same About your internal validation, please note that the numbering scheme was changed with version 2.0 $ Which internal validation? Are you talking about `cygpath`? https://sourceware.org/ml/cygwin-announce/2015-04/msg00046.html I suggest you to consider 2.x version as the successor of 1.7.x. $ I am considering 2.7 instead of 2.1 What are you talking about 1.7? Regards Marco $ By the way I still don't know how to answer/reply a message from this mailing list. I have to do polling over https://www.cygwin.com/ml/cygwin/2017-05/ and copy/paste everything into a new e-mail. I doubt this is the correct way to communicate. Do you have a clue? -- 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 ________ . References: o Re: cygpath compatiblity break (v2.1 -> v2.7) . From: Chevallier Yves o Re: cygpath compatiblity break (v2.1 -> v2.7) . From: Marco Atzeri o RE: cygpath compatiblity break (v2.1 -> v2.7) . From: Chevallier Yves Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next] -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 10/05/2017 11:12, Chevallier Yves wrote: Unfortunately I haven't tried 2.8 because we've already validated 2.7 internally and I would need at least 3 months to access to 2.8. That said I searched for a release note with information about cygpath, but I haven't find any. Bottom Post in this mailing list. Please. Cygpath is part of the cygwin package. The source specific of "cygpath" is unchanged by ~ 6 months. The issue you see was likely a change inside the cygwin dll. About your internal validation, please note that the numbering scheme was changed with version 2.0 https://sourceware.org/ml/cygwin-announce/2015-04/msg00046.html I suggest you to consider 2.x version as the successor of 1.7.x. Regards Marco -- 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
RE: cygpath compatiblity break (v2.1 -> v2.7)
Unfortunately I haven't tried 2.8 because we've already validated 2.7 internally and I would need at least 3 months to access to 2.8. That said I searched for a release note with information about cygpath, but I haven't find any. -Original Message- From: Marco Atzeri [mailto:marco.atz...@gmail.com] Sent: mercredi 10 mai 2017 09:14 To: cygwin@cygwin.com Cc: Chevallier Yves Subject: Re: cygpath compatiblity break (v2.1 -> v2.7) On 10/05/2017 08:00, Chevallier Yves wrote: > Dear All, > > I tried to understand how the mailing list work, but I cannot find any thread > number or message number from the following. > > Moreover we haven't discussed my issue with `cygpath` which is a serious > compatibility break in my toolchain. Changing the executable doesn't change > anything because I think `cygpath` is somehow linked to a Cygwin dll which > have the bug. > > So two questions in this thread: > > 1. How can I participate to the thread and use this mailing list properly? > 2. What workaround can I use with my Cypath issue? > > Regards, > Yves Have you tried 2.8 ? https://cygwin.com/ml/cygwin/2017-04/msg00156.html -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 10/05/2017 08:00, Chevallier Yves wrote: Dear All, I tried to understand how the mailing list work, but I cannot find any thread number or message number from the following. Moreover we haven't discussed my issue with `cygpath` which is a serious compatibility break in my toolchain. Changing the executable doesn't change anything because I think `cygpath` is somehow linked to a Cygwin dll which have the bug. So two questions in this thread: 1. How can I participate to the thread and use this mailing list properly? 2. What workaround can I use with my Cypath issue? Regards, Yves Have you tried 2.8 ? https://cygwin.com/ml/cygwin/2017-04/msg00156.html -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
Dear All, I tried to understand how the mailing list work, but I cannot find any thread number or message number from the following. Moreover we haven't discussed my issue with `cygpath` which is a serious compatibility break in my toolchain. Changing the executable doesn't change anything because I think `cygpath` is somehow linked to a Cygwin dll which have the bug. So two questions in this thread: 1. How can I participate to the thread and use this mailing list properly? 2. What workaround can I use with my Cypath issue? Regards, Yves From: Brian Inglis To: cygwin at cygwin dot com Date: Wed, 26 Apr 2017 10:37:34 -0600 Subject: Re: cygpath compatiblity break (v2.1 -> v2.7) Authentication-results: sourceware.org; auth=none References: <0d835e9b9cd07f40a48423f80d3b5a704bc07...@usa7109mb022.na.xerox.net> <7ddd6386-4463-ec7e-14b0-dc1b719c9...@systematicsw.ab.ca> <36feeb13-b77d-1c2a-d31a-e1e6241e4...@systematicsw.ab.ca> <3094b7cc-7745-1160-e77e-0ef8b90bd...@gmail.com> Reply-to: Brian dot Inglis at SystematicSw dot ab dot ca On 2017-04-26 09:20, cyg Simple wrote: > On 4/25/2017 9:51 PM, Brian Inglis wrote: >> On 2017-04-25 19:12, Brian Inglis wrote: >>> On 2017-04-25 03:16, Andrew Schulman wrote: >>>>> From: Yves Chevallier >>>>>> How can I use this mailing list to answer a mail that I >>>>>> only find from this link >>>>>> https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? >>>>> Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No >>>>> need to add a subject or body. It will send you the message, >>>>> and you can reply to that. >>>> Whoa. This should be documented somewhere. >>>> Looks like the 207653 comes from the Return-Path header when >>>> you view the raw message content. >>> It's documented in all subscription confirmation and acknowledgement >>> emails from the mailing list manager, unless you subscribed before >>> ezmlm was used, and you can get it by sending a blank plain text >>> email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. >> [last line scrambled by email address obscurer] >> email to -help at cygwin dot com e.g. cygwin-help at cygwin dot com > I was going to state the same yesterday but I gave it a try first. > The resulting mail doesn't explain the use of cygwin-get.MSGID that I > saw. It mostly refers to the FAQ on cygwin.com. Other lists' help is more informative - single message retrieval based on the ml msg# is implied, but the source of that number is not obvious: "To get messages 123 through 145 (a maximum of 100 per request), mail: To get an index with subject and author for messages 123-456 , mail: They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: " should be added to the cygwin ml help, as should the source of the msg# as being the number in the raw message Return-path: header, and -help should be a command, and added to the ml help. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 2017-04-26 09:20, cyg Simple wrote: > On 4/25/2017 9:51 PM, Brian Inglis wrote: >> On 2017-04-25 19:12, Brian Inglis wrote: >>> On 2017-04-25 03:16, Andrew Schulman wrote: > From: Yves Chevallier >> How can I use this mailing list to answer a mail that I >> only find from this link >> https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? > Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No > need to add a subject or body. It will send you the message, > and you can reply to that. Whoa. This should be documented somewhere. Looks like the 207653 comes from the Return-Path header when you view the raw message content. >>> It's documented in all subscription confirmation and acknowledgement >>> emails from the mailing list manager, unless you subscribed before >>> ezmlm was used, and you can get it by sending a blank plain text >>> email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. >> [last line scrambled by email address obscurer] >> email to -help at cygwin dot com e.g. cygwin-help at cygwin dot com > I was going to state the same yesterday but I gave it a try first. > The resulting mail doesn't explain the use of cygwin-get.MSGID that I > saw. It mostly refers to the FAQ on cygwin.com. Other lists' help is more informative - single message retrieval based on the ml msg# is implied, but the source of that number is not obvious: "To get messages 123 through 145 (a maximum of 100 per request), mail: To get an index with subject and author for messages 123-456 , mail: They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: " should be added to the cygwin ml help, as should the source of the msg# as being the number in the raw message Return-path: header, and -help should be a command, and added to the ml help. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
RE: cygpath compatiblity break (v2.1 -> v2.7)
From: cyg Simple > I was going to state the same yesterday but I gave it a try first. The > resulting mail doesn't explain the use of cygwin-get.MSGID that I saw. > It mostly refers to the FAQ on cygwin.com. Well, there is the following. Not saying it is easy to find. https://untroubled.org/ezmlm/manual/Sending-commands.html#Sending-commands --Ken Nellis -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 4/25/2017 9:51 PM, Brian Inglis wrote: > On 2017-04-25 19:12, Brian Inglis wrote: >> On 2017-04-25 03:16, Andrew Schulman wrote: From: Yves Chevallier > How can I use this mailing list to answer a mail that I only > find from this link > https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No need to add a subject or body. It will send you the message, and you can reply to that. >>> Whoa. This should be documented somewhere. >> >> It's documented in all subscription confirmation and acknowledgement >> emails from the mailing list manager, unless you subscribed before >> ezmlm was used, and you can get it by sending a blank plain text >> email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. > [last line scrambled by email address obscurer] > email to -help at cygwin dot com e.g. cygwin-help at cygwin dot com > I was going to state the same yesterday but I gave it a try first. The resulting mail doesn't explain the use of cygwin-get.MSGID that I saw. It mostly refers to the FAQ on cygwin.com. -- cyg Simple -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 2017-04-25 19:12, Brian Inglis wrote: > On 2017-04-25 03:16, Andrew Schulman wrote: >>> From: Yves Chevallier How can I use this mailing list to answer a mail that I only find from this link https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? >>> Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No need >>> to add a subject or body. It will send you the message, and you can >>> reply to that. >> Whoa. This should be documented somewhere. > > It's documented in all subscription confirmation and acknowledgement > emails from the mailing list manager, unless you subscribed before > ezmlm was used, and you can get it by sending a blank plain text > email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. [last line scrambled by email address obscurer] email to -help at cygwin dot com e.g. cygwin-help at cygwin dot com -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 2017-04-25 03:16, Andrew Schulman wrote: >> From: Yves Chevallier >>> How can I use this mailing list to answer a mail that I only >>> find from this link >>> https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? >> Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No need >> to add a subject or body. It will send you the message, and you can >> reply to that. > Whoa. This should be documented somewhere. It's documented in all subscription confirmation and acknowledgement emails from the mailing list manager, unless you subscribed before ezmlm was used, and you can get it by sending a blank plain text email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
> From: Yves Chevallier > > ... > > How can I use this mailing list to answer a mail that I only find from > > this [link](https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html)? > > ... > > Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No need to add > a subject or body. It will send you the message, and you can reply to that. Whoa. This should be documented somewhere. Looks like the 207653 comes from the Return-Path header when you view the raw message content. -- 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
RE: cygpath compatiblity break (v2.1 -> v2.7)
From: Yves Chevallier > ... > How can I use this mailing list to answer a mail that I only find from > this [link](https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html)? > ... Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No need to add a subject or body. It will send you the message, and you can reply to that. --Ken Nellis
Re: cygpath compatiblity break (v2.1 -> v2.7)
Well, I don't have the same behavior and I have the latest version of `cygpath.exe` according to my setup: $ cd / $ mkdir foo $ touch foo.exe $ cygpath -w foo foo $ cd foo $ touch foo.exe $ cygpath -w foo foo.exe $ cygpath --version cygpath (cygwin) 2.8.0 Path Conversion Utility Copyright (C) 1998 - 2017 Cygwin Authors This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. How can I use this mailing list to answer a mail that I only find from this [link](https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html)? Is there any issue tracker for Cygwin? Are you guys on GitHub? Do you have a platform that supports at least Markdown? > latest is 2.8.0-1 > https://cygwin.com/ml/cygwin-announce/2017-04/msg1.html > In any directory, I see > $ touch foo.exe > $ cygpath -w foo > foo.exe -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 13/04/2017 14:34, Chevallier Yves wrote: I get a very different behaviour with `cygpath` after I upgrade my version of Cygwin. Why? and how can I fix it? With Cygwin 2.7: ``` $ uname -a CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin $ cygpath --version cygpath (cygwin) 2.7.0 $ cd / $ touch foo.exe $ cygpath -m foo foo.exe $ cd $ touch foo.exe $ cygpath -m foo foo ``` latest is 2.8.0-1 https://cygwin.com/ml/cygwin-announce/2017-04/msg1.html In any directory, I see $ touch foo.exe $ cygpath -w foo foo.exe -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 13. 4. 2017 16:24, David Macek wrote: > On 13. 4. 2017 14:34, Chevallier Yves wrote: >> I get a very different behaviour with `cygpath` after I upgrade my version >> of Cygwin. Why? and how can I fix it? >> >> With Cygwin 2.7: >> >> ``` >> $ uname -a >> CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin >> $ cygpath --version >> cygpath (cygwin) 2.7.0 >> >> $ cd / >> $ touch foo.exe >> $ cygpath -m foo >> foo.exe >> >> $ cd >> $ touch foo.exe >> $ cygpath -m foo >> foo >> ``` > > I can't reproduce this. I see both as `foo` on Cygwin (and both as `foo.exe` > on MSYS2). Can you post the output of your `mount`, also `ls foo*` from both > directories? My mistake, I was using Cygwin v2.5.x. I updated to v2.8.0 and now I see both as `foo.exe`. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 13. 4. 2017 14:34, Chevallier Yves wrote: > I get a very different behaviour with `cygpath` after I upgrade my version of > Cygwin. Why? and how can I fix it? > > With Cygwin 2.7: > > ``` > $ uname -a > CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin > $ cygpath --version > cygpath (cygwin) 2.7.0 > > $ cd / > $ touch foo.exe > $ cygpath -m foo > foo.exe > > $ cd > $ touch foo.exe > $ cygpath -m foo > foo > ``` I can't reproduce this. I see both as `foo` on Cygwin (and both as `foo.exe` on MSYS2). Can you post the output of your `mount`, also `ls foo*` from both directories? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 4/13/2017 10:02 AM, Eric Blake wrote: > On 04/13/2017 08:59 AM, cyg Simple wrote: > > [an unreadable encrypted message] > > You may want to fix your email settings; encrypted messages should > generally not be used when sending to a mailing list. > Sorry, Enigmail settings must have changed inadvertently. I said: On 4/13/2017 8:34 AM, Chevallier Yves wrote: > I get a very different behaviour with `cygpath` after I upgrade my version of Cygwin. Why? and how can I fix it? > What problem does the added ".exe" cause? > With Cygwin 2.7: > > ``` > $ uname -a > CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin > $ cygpath --version > cygpath (cygwin) 2.7.0 > > $ cd / > $ touch foo.exe > $ cygpath -m foo > foo.exe > > $ cd > $ touch foo.exe > $ cygpath -m foo > foo > ``` This appears to be a regression but why are we creating files in the root directory? > > With Cygwin 2.1: > ``` > $ uname -a > CYGWIN_NT-6.1-WOW CPT 2.1.0(0.287/5/3) 2015-07-14 21:26 i686 Cygwin > $ cygpath --version > cygpath (cygwin) 2.1.0 > > $ cd / > $ touch foo.exe > $ cygpath -m foo > foo > > $ cd > $ touch foo.exe > $ cygpath -m foo > foo -- cyg Simple -- 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
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 04/13/2017 08:59 AM, cyg Simple wrote: [an unreadable encrypted message] You may want to fix your email settings; encrypted messages should generally not be used when sending to a mailing list. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: cygpath compatiblity break (v2.1 -> v2.7)
binD9fTojUuRq.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message
Re: cygpath (reprised)
On 3/1/2017 8:12 AM, Andrey Repin wrote: > Greetings, cyg Simple! > >> On 2/25/2017 8:13 PM, Andrey Repin wrote: >>> Greetings, cyg Simple! >>> Also a : isn't a valid character for a name in Windows. Cygwin uses some magic to represent it in UNICODE format though. >>> >>> It isn't a valid file "name" character, yes, but it is still a meaningful >>> character in pathname under windows. >>> Just the meaning of it is far from regular file name semantics. >>> > >> Not when specifying ./a:b which was the example being discussed. > > We were discussing "a:b", not "./a:b". Then you need to re-read the elided content. An example of ./a:b was given and what I responded to. -- cyg Simple -- 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
Re: cygpath (reprised)
Greetings, cyg Simple! > On 2/25/2017 8:13 PM, Andrey Repin wrote: >> Greetings, cyg Simple! >> >>> Also a : isn't a valid character for a name in Windows. Cygwin uses >>> some magic to represent it in UNICODE format though. >> >> It isn't a valid file "name" character, yes, but it is still a meaningful >> character in pathname under windows. >> Just the meaning of it is far from regular file name semantics. >> > Not when specifying ./a:b which was the example being discussed. We were discussing "a:b", not "./a:b". -- With best regards, Andrey Repin Wednesday, March 1, 2017 16:11:45 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
Re: cygpath (reprised)
On 2/27/2017 9:03 AM, Nellis, Kenneth (Conduent) wrote: > From: cyg Simple >> On 2/21/2017 1:22 PM, Nellis, Kenneth (Conduent) wrote: >>> I suppose one could argue that, by using -w, that cygpath might assume that >>> it >>> is converting *from* a POSIX path, and therefore the colon would not >>> indicate >>> a drive letter--wouldn't that make sense?--but I’ll let someone else take up >>> that battle. ☺ >> >> I would almost agree except for the help description of the -w option. >> ... > > Hmm. Not sure that I see that. From the man page: > > The cygpath program is a utility that converts Windows native filenames to > Cygwin > POSIX-style pathnames and vice versa. > A general description of the application. What does the man page say about the -w option itself? If nothing then you need to see the cygpath --help itself. > I read this as converting one format to the other. The -w, --windows help text simply says "print windows form of NAMEs (C:\WINNT)". This says nothing about what to expect of the conversion other than it should be a valid windows path. It doesn't state what happens with garbage input so you should assume an undefined behavior. Back to the examples 'a:b' is always valid input while './a:b' isn't always valid for Windows; although it could be. So what should happen for the latter is if possible the `:' character be converted to its UNICODE representation as NTFS can use that character as part of the file name. But if not possible you get back what you entered. This does leave you with the need to filter the result since garbage begets a stinking mess. Always stay away from the corner cases if you wish to never have issues. Otherwise be ready to deal with them in continuous rigor. -- cyg Simple -- 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
Re: cygpath (reprised)
On 2/25/2017 8:13 PM, Andrey Repin wrote: > Greetings, cyg Simple! > >> Also a : isn't a valid character for a name in Windows. Cygwin uses >> some magic to represent it in UNICODE format though. > > It isn't a valid file "name" character, yes, but it is still a meaningful > character in pathname under windows. > Just the meaning of it is far from regular file name semantics. > Not when specifying ./a:b which was the example being discussed. -- cyg Simple -- 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
RE: cygpath (reprised)
From: cyg Simple > On 2/21/2017 1:22 PM, Nellis, Kenneth (Conduent) wrote: > > I suppose one could argue that, by using -w, that cygpath might assume that > > it > > is converting *from* a POSIX path, and therefore the colon would not > > indicate > > a drive letter--wouldn't that make sense?--but I’ll let someone else take up > > that battle. ☺ > > I would almost agree except for the help description of the -w option. > ... Hmm. Not sure that I see that. From the man page: The cygpath program is a utility that converts Windows native filenames to Cygwin POSIX-style pathnames and vice versa. I read this as converting one format to the other. --Ken Nellis -- 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
Re: cygpath (reprised)
Greetings, cyg Simple! > Also a : isn't a valid character for a name in Windows. Cygwin uses > some magic to represent it in UNICODE format though. It isn't a valid file "name" character, yes, but it is still a meaningful character in pathname under windows. Just the meaning of it is far from regular file name semantics. -- With best regards, Andrey Repin Sunday, February 26, 2017 04:12:43 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
Re: cygpath (reprised)
On 2/21/2017 1:22 PM, Nellis, Kenneth (Conduent) wrote: > From: Andrey Repin >>> But, consider the following: >> >>> $ cygpath -w a:b | od -An -tx1c >>> 41 3a 62 0a >>>A : b \n >>> $ >> >>> Instead of the special character colon (:), shouldn't cygpath be showing >>> something in the Unicode Private Use area? >> >> No, it shouldn't. >> You've requested a name "b" in the current directory on the disk "A:", or >> a file substream "b" of the file "a". >> Both are valid system paths. > > Right. Thanx. I wondered why the "a" got up-cased. > > I suppose one could argue that, by using -w, that cygpath might assume that > it > is converting *from* a POSIX path, and therefore the colon would not indicate > a drive letter--wouldn't that make sense?--but I’ll let someone else take up > that battle. ☺ > I would almost agree except for the help description of the -w option. Also a : isn't a valid character for a name in Windows. Cygwin uses some magic to represent it in UNICODE format though. > Also, in the following, I would expect cygpath to figure out that I *am not* > specifying a drive letter: > > $ cygpath -w ./a:b | od -An -tx1c > 41 3a 62 0a >A : b \n > $ > Consider the following as what should happen with "./a:b" but the current result of "a:b" could already be considered correct. With the following I think the output give fro "./a:b" is incorrect. Not withstanding the argument for relational output of the windows path. $ cygpath -w ../a:b | od -An -tx1c 43 3a 5c 6f 70 74 5c 63 79 67 77 69 6e 36 34 5c C : \ o p t \ c y g w i n 6 4 \ 68 6f 6d 65 5c 61 ef 80 ba 62 0a h o m e \ a 357 200 272 b \n -- cyg Simple -- 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
RE: cygpath (reprised)
From: Andrey Repin > > But, consider the following: > > > $ cygpath -w a:b | od -An -tx1c > > 41 3a 62 0a > >A : b \n > > $ > > > Instead of the special character colon (:), shouldn't cygpath be showing > > something in the Unicode Private Use area? > > No, it shouldn't. > You've requested a name "b" in the current directory on the disk "A:", or > a file substream "b" of the file "a". > Both are valid system paths. Right. Thanx. I wondered why the "a" got up-cased. I suppose one could argue that, by using -w, that cygpath might assume that it is converting *from* a POSIX path, and therefore the colon would not indicate a drive letter--wouldn't that make sense?--but I’ll let someone else take up that battle. ☺ Also, in the following, I would expect cygpath to figure out that I *am not* specifying a drive letter: $ cygpath -w ./a:b | od -An -tx1c 41 3a 62 0a A : b \n $ But I don't have a dog in this fight, either. (Replying to a direct reply from Mr. Repin rather than from the list, so hoping this doesn't break message threading.) --Ken Nellis
Re: cygpath (reprised)
Greetings, Nellis, Kenneth (Conduent)! > I followed and understood the discussion to all the recent cygpath postings, > so I understand and expect the following: > $ cygpath -w 'a*b' | od -An -tx1c > 61 ef 80 aa 62 0a >a 357 200 252 b \n > $ > But, consider the following: > $ cygpath -w a:b | od -An -tx1c > 41 3a 62 0a >A : b \n > $ > Instead of the special character colon (:), shouldn't cygpath be showing > something in the Unicode Private Use area? No, it shouldn't. You've requested a name "b" in the current directory on the disk "A:", or a file substream "b" of the file "a". Both are valid system paths. -- With best regards, Andrey Repin Tuesday, February 21, 2017 21:01:01 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
Re: cygpath
On Feb 15 14:41, Nellis, Kenneth (Conduent) wrote: > From: Corinna Vinschen > > On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote: > > > From: Andrey Repin > > > > See > > > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars > > > > > > This reference says: > > > ... > > > I propose the following: > > > ... > > > > Patched. > > Thanx for that, but not sure what "Patched" means in this context. > In any case, I don't see the change to the web page. Docs are in git, patch pushed. The website will catch up eventually... ...make that "now". I actually forgot to upload the 2.7.0 docs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
RE: cygpath
From: Corinna Vinschen > On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote: > > From: Andrey Repin > > > See > > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars > > > > This reference says: > > ... > > I propose the following: > > ... > > Patched. Thanx for that, but not sure what "Patched" means in this context. In any case, I don't see the change to the web page. --Ken Nellis
Re: cygpath
On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote: > From: Andrey Repin > > See > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars > > This reference says: > > > All of the above characters, except for the backslash, are converted to > > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private > > use area") when creating or accessing files. > > It does not say *how* they are converted. In fact, by observation, > they appear to be converted by having 0xF000 added to their code points. > Perhaps this text could be updated accordingly. > > I propose the following: > > > All of the above characters, except for the backslash, are converted to > > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private > > use area") when creating or accessing files by adding 0xf000 to the > > forbidden characters' code points. Patched. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: cygpath -w converts relative paths to absolute windows paths
Am 13.02.2017 um 16:16 schrieb Corinna Vinschen: On Feb 12 18:38, Thomas Wolff wrote: Am 12.02.2017 um 12:23 schrieb Corinna Vinschen: On Feb 7 14:35, Roger Qiu wrote: Hi, I've found that `cygpath --windows '../` will give back an absolute windows path. I thought this would only happen if you provide the `--absolute` flag, or when the path is a special cygwin path. But this occurs just for normal directories. I have come across a situation where I need to convert ntfs symlinks to unix symlinks and back. Sometimes these symlinks have relative paths them. Now by using cygpath --windows, I get back absolute paths, which means the integrity of the symlink isn't preserved. Can `cygpath --windows '../directory'` give back `..\directory` for paths aren't special cygwin paths? These relative backslashes are supported in Windows right now. Not easily. All paths are evaluated as absolute paths inside Cygwin. The result of the path conversion is always an absolute path. A relative path is generated from there by checking if the path prefix in POSIX notation is identical to the current working directory. If not, the path stays absolute. Naturally, if you use a "..", the resulting path does not match the CWD anymore, so you're out. How about converting getcwd(), too, and comparing that? Converting to what? And how's that different from what I describe above? I was looking at path.cc, function mkrelpath, and (without tracing anything) assumed this would be the relevant function and had the impression that, when comparing path_prefix_p (cwd_win32, path, ...), path might be "normalized" (resolving links and folding ".." components) while cwd_win32 might not. If that's the case, it might be sufficient to "normalize" cwd_win32 as well. Btw., did you see https://cygwin.com/ml/cygwin/2017-01/msg00404.html? No, I hadn't, sorry. Will respond there. -- Thomas -- 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
RE: cygpath
From: Andrey Repin > See > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars This reference says: > All of the above characters, except for the backslash, are converted to > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private > use area") when creating or accessing files. It does not say *how* they are converted. In fact, by observation, they appear to be converted by having 0xF000 added to their code points. Perhaps this text could be updated accordingly. I propose the following: > All of the above characters, except for the backslash, are converted to > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private > use area") when creating or accessing files by adding 0xf000 to the > forbidden characters' code points. --Ken Nellis
Re: cygpath -w converts relative paths to absolute windows paths
On Feb 12 18:38, Thomas Wolff wrote: > Am 12.02.2017 um 12:23 schrieb Corinna Vinschen: > > On Feb 7 14:35, Roger Qiu wrote: > > > Hi, > > > > > > I've found that `cygpath --windows '../` will give back an absolute > > > windows > > > path. > > > > > > I thought this would only happen if you provide the `--absolute` flag, or > > > when the path is a special cygwin path. > > > > > > But this occurs just for normal directories. > > > > > > I have come across a situation where I need to convert ntfs symlinks to > > > unix > > > symlinks and back. Sometimes these symlinks have relative paths them. Now > > > by > > > using cygpath --windows, I get back absolute paths, which means the > > > integrity of the symlink isn't preserved. > > > > > > Can `cygpath --windows '../directory'` give back `..\directory` for paths > > > aren't special cygwin paths? These relative backslashes are supported in > > > Windows right now. > > Not easily. All paths are evaluated as absolute paths inside Cygwin. > > The result of the path conversion is always an absolute path. A relative > > path is generated from there by checking if the path prefix in POSIX > > notation is identical to the current working directory. If not, the > > path stays absolute. Naturally, if you use a "..", the resulting path > > does not match the CWD anymore, so you're out. > How about converting getcwd(), too, and comparing that? Converting to what? And how's that different from what I describe above? Btw., did you see https://cygwin.com/ml/cygwin/2017-01/msg00404.html? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: cygpath -w converts relative paths to absolute windows paths
Am 12.02.2017 um 12:23 schrieb Corinna Vinschen: On Feb 7 14:35, Roger Qiu wrote: Hi, I've found that `cygpath --windows '../` will give back an absolute windows path. I thought this would only happen if you provide the `--absolute` flag, or when the path is a special cygwin path. But this occurs just for normal directories. I have come across a situation where I need to convert ntfs symlinks to unix symlinks and back. Sometimes these symlinks have relative paths them. Now by using cygpath --windows, I get back absolute paths, which means the integrity of the symlink isn't preserved. Can `cygpath --windows '../directory'` give back `..\directory` for paths aren't special cygwin paths? These relative backslashes are supported in Windows right now. Not easily. All paths are evaluated as absolute paths inside Cygwin. The result of the path conversion is always an absolute path. A relative path is generated from there by checking if the path prefix in POSIX notation is identical to the current working directory. If not, the path stays absolute. Naturally, if you use a "..", the resulting path does not match the CWD anymore, so you're out. How about converting getcwd(), too, and comparing that? -- Thomas -- 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
Re: cygpath -w converts relative paths to absolute windows paths
On Feb 7 14:35, Roger Qiu wrote: > Hi, > > I've found that `cygpath --windows '../` will give back an absolute windows > path. > > I thought this would only happen if you provide the `--absolute` flag, or > when the path is a special cygwin path. > > But this occurs just for normal directories. > > I have come across a situation where I need to convert ntfs symlinks to unix > symlinks and back. Sometimes these symlinks have relative paths them. Now by > using cygpath --windows, I get back absolute paths, which means the > integrity of the symlink isn't preserved. > > Can `cygpath --windows '../directory'` give back `..\directory` for paths > aren't special cygwin paths? These relative backslashes are supported in > Windows right now. Not easily. All paths are evaluated as absolute paths inside Cygwin. The result of the path conversion is always an absolute path. A relative path is generated from there by checking if the path prefix in POSIX notation is identical to the current working directory. If not, the path stays absolute. Naturally, if you use a "..", the resulting path does not match the CWD anymore, so you're out. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: cygpath -w converts relative paths to absolute windows paths
On 2/8/2017 5:42 PM, Thomas Wolff wrote: > Hi Andrey, > > Am 08.02.2017 um 11:54 schrieb Andrey Repin: >> Greetings, Thomas Wolff! >> >>> Am 07.02.2017 um 16:30 schrieb Andrey Repin: Greetings, Roger Qiu! > I've found that `cygpath --windows '../` will give back an absolute > windows path. > ... ".." is a special path, that can't be safely converted. >>> How is the special meaning of ".." so much different in Windows than in >>> Cygwin/Linux/POSIX that it could not be mapped? >>> Things like dir .., cd .., type ..\sub\file all work comparably. >> Comparable? May be. Predictable? >> https://bugs.php.net/bug.php?id=73797 > I don't know what __DIR__ is supposed to mean in PHP. Anyway, handling It's simply a constant of the directory for the file in which __DIR__ appears. The constant has a namespace relative to the file. > ".." is not predictable even within Linux/Cygwin, you could see > something like: >> ls dir1/file > dir1/file >> cd dir2 >> ls ../dir1/file > No such file or directory > > (if dir2 is a link), or can have surprising effects of cd vs. cd -P. > I don't see how that should exclude ".." from being transformed to ".." > by cygpath -w, even if the result may be somewhat unexpected in some > border cases (which I haven't seen yet). I agree. -- cyg Simple -- 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
Re: cygpath
On 2017-02-10 12:07, Gluszczak, Glenn wrote:
> Isn’t this a defect in cygpath? Looks like memory corruption.
> %%%cygpath -w /usr/tmp/*
> C:\cygwin\usr\tmp\
> %%%cygpath -w /usr/non-existent/*
> C:\cygwin\usr\non-existent\�[W��
For proper interpretation of a Unix path name, all but the last component must
exist, and that is expected to be a file system entry which will be created.
Unix wild cards are looked up and expanded by the shell prior to command
execution, so are expected to be existing path names used as input to a
command, otherwise they are passed to the command as is: if used as an input
path name, it should not exist; if used as an output path name, it will be
created if all but the last component exist, otherwise it should fail as a
directory component in the path does not exist.
One exception is mkdir -p, and there may be some similar commands which will
create multiple explicit directory tree entries in a path.
AFAIK there are no Unix commands which allow output wild card path names and
interpret them as being the same as the input names, but there are some cmd
shell commands which allow or expect this e.g. RENAME *.bat *.cmd, which on
Unix has to be done with multiple commands in a a loop e.g.
for bat in *.bat; do mv $bat ${bat%.bat}.cmd; done
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
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
Re: cygpath
On 11/02/2017 00:05, Eliot Moss wrote: > On 2/10/2017 6:50 PM, Sam Edge wrote: > >> Sorry, did anyone actually read Andrey's post? > > Yes, but I was going through the emails in order and responded > to the earlier one before I got to the later one. Sorry to have > added noise to the list ... > No prob. Perhaps a little over-exasperated here. sorry. Not an excuse but it's been a long week! Off to watch Tucker and Dale ... :-) -- Sam Edge -- 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
Re: cygpath
On 2/10/2017 6:50 PM, Sam Edge wrote: Sorry, did anyone actually read Andrey's post? Yes, but I was going through the emails in order and responded to the earlier one before I got to the later one. Sorry to have added noise to the list ... EM -- 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
Re: cygpath
On 10/02/2017 23:17, Eliot Moss wrote: > On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote: >> * is a legal character for ls but perhaps not cygpath? I don't know. >> No files or directories are using * in the name. >> >> Not sure about incorrect terminal settings as I never touched any. >> It shows up in mintty and ssh equally. The characters that appear vary. >> >> Some non-existent paths do *not* produce the gibberish. >> >> %%%cygpath -w /aaa/bbb/* >> C:\cygwin\aaa\bbb\ > > Yes, but I found something interesting when I did this: > > echo "$(cygpath -w /usr/non-existent/*)" > mytemp > > od -c mytemp > > revealed that there is a three-byte sequence after the > output of > > C:\cygwin\usr\non-existent\ > > and before the newline added by echo. I guess it's > some representation of * that does not show up on the > terminal, but it did strike me as a little strange ... > > Regards - EM > > -- > 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 > > Sorry, did anyone actually read Andrey's post? (Hint: Read https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars again.) The three byte sequence is the UTF-8 representation of U+F02A i.e. ASCII for '*' but in the private use area of Unicode. This is how the Cygwin DLL stores ASCII characters in pathnames that are forbidden in Windows but that are valid in POSIX. The directory entry write functions convert them to private area and the read functions convert them back to Unicode. The cygpath utility therefore does exactly the same on the assumption that the result is going to be passed to Windows programs that are going to manipulate the directory entry in some way - open the file for example. That they display incorrectly is an inevitable side effect of this work-around. Generally, all you need to do is accept the Copenhagen interpretation in your scripts and just calculate. ;-) The only thing you need to be careful of is that if you really mean to pass the glob to your Windows app, you leave it out of the string passed to cygpath e.g. cygstart some-exe "$(cygpath -w "some-posix-path/")"\* instead of cygstart some-exe "$(cygpath -w "some-posix-path/*")" -- Sam Edge -- 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
Re: cygpath
On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote: * is a legal character for ls but perhaps not cygpath? I don't know. No files or directories are using * in the name. Not sure about incorrect terminal settings as I never touched any. It shows up in mintty and ssh equally. The characters that appear vary. Some non-existent paths do *not* produce the gibberish. %%%cygpath -w /aaa/bbb/* C:\cygwin\aaa\bbb\ Yes, but I found something interesting when I did this: echo "$(cygpath -w /usr/non-existent/*)" > mytemp od -c mytemp revealed that there is a three-byte sequence after the output of C:\cygwin\usr\non-existent\ and before the newline added by echo. I guess it's some representation of * that does not show up on the terminal, but it did strike me as a little strange ... Regards - EM -- 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
Re: cygpath
On Fri, Feb 10, 2017 at 1:34 PM, Andrey Repin wrote: > Greetings, Gluszczak, Glenn! > >> * is a legal character for ls but perhaps not cygpath? > > "*" is not a legal path name character. And cygpath expects a path. AFAICT, '*' is a legal character in a filename or directory name on Posix systems and Linux. Source: https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words -- 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
Re: cygpath
On Fri, Feb 10, 2017 at 1:46 PM, Gluszczak, Glenn wrote: > I suppose the glob explanation from Michael explains this behavior in sh. > Though unsupported, it seems to work (probably some side cases do not). It seems to me that the behavior is supported and working. Bash or sh takes an unescaped argument /usr/bin/* and expands it to a list of names, which it provides as an array of arguments to the called program, cygpath in this case. Then cygpath converts each and outputs each result. If the user escapes the argument in someway, the asterisk survives and is treated as a Unix file name character. If there is no glob expansion, in the case of the unescaped argument /usr/nonexistent/* for example, Bash only passes one argument, and the asterisk in that is treated as a filename character. I think when the output to your terminal is weird, it is because of locale settings or code pages that either hide or garble the output of the unicode character. When the output is piped to od as Andre does, the output is clearly the UTF8 byte sequence for U+F02A. -- 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
RE: cygpath
I suppose the glob explanation from Michael explains this behavior in sh. Though unsupported, it seems to work (probably some side cases do not). $ cygpath -w /usr/bin/* C:\cygwin64\bin\[.exe C:\cygwin64\bin\2to3 C:\cygwin64\bin\addftinfo.exe C:\cygwin64\bin\addr2line.exe C:\cygwin64\bin\whatis.exe C:\cygwin64\bin\ar.exe C:\cygwin64\bin\arch.exe C:\cygwin64\bin\as.exe C:\cygwin64\bin\ash.exe C:\cygwin64\bin\gawk.exe C:\cygwin64\bin\b2sum.exe -Original Message- Greetings, Gluszczak, Glenn! > * is a legal character for ls but perhaps not cygpath? "*" is not a legal path name character. And cygpath expects a path. > I don't know. > No files or directories are using * in the name. See above. > Not sure about incorrect terminal settings as I never touched any. > It shows up in mintty and ssh equally. The characters that appear vary. For me, it shows a single blank box character. (The required character is missing from the font I'm using in mintty.) > Some non-existent paths do *not* produce the gibberish. > %%%cygpath -w /aaa/bbb/* > C:\cygwin\aaa\bbb\ Works equally for me. $ cygpath -w /usr/non-existent/* | od -t x1 000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77 020 69 6e 5f 36 34 5c 75 73 72 5c 6e 6f 6e 2d 65 78 040 69 73 74 65 6e 74 5c ef 80 aa 0a 053 $ cygpath -w /aaa/bbb/* | od -t x1 000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77 020 69 6e 5f 36 34 5c 61 61 61 5c 62 62 62 5c ef 80 040 aa 0a 042 Also please don't top-post https://cygwin.com/acronyms/#TOFU and don't quote raw email addresses. https://cygwin.com/lists.html -- With best regards, Andrey Repin Saturday, February 11, 2017 00:27:02 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
Re: cygpath
Greetings, Gluszczak, Glenn! > * is a legal character for ls but perhaps not cygpath? "*" is not a legal path name character. And cygpath expects a path. > I don't know. > No files or directories are using * in the name. See above. > Not sure about incorrect terminal settings as I never touched any. > It shows up in mintty and ssh equally. The characters that appear vary. For me, it shows a single blank box character. (The required character is missing from the font I'm using in mintty.) > Some non-existent paths do *not* produce the gibberish. > %%%cygpath -w /aaa/bbb/* > C:\cygwin\aaa\bbb\ Works equally for me. $ cygpath -w /usr/non-existent/* | od -t x1 000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77 020 69 6e 5f 36 34 5c 75 73 72 5c 6e 6f 6e 2d 65 78 040 69 73 74 65 6e 74 5c ef 80 aa 0a 053 $ cygpath -w /aaa/bbb/* | od -t x1 000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77 020 69 6e 5f 36 34 5c 61 61 61 5c 62 62 62 5c ef 80 040 aa 0a 042 Also please don't top-post https://cygwin.com/acronyms/#TOFU and don't quote raw email addresses. https://cygwin.com/lists.html -- With best regards, Andrey Repin Saturday, February 11, 2017 00:27:02 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
RE: cygpath
Thanks for the explanation. Just odd how cmd.exe only sometimes misbehaves. %%%cygpath -w /usr/a/b/* C:\cygwin\usr\a\b\ %%%cygpath -w /a/b/* C:\cygwin\a\b\ %%%cygpath -w /a/b/c/* C:\cygwin\a\b\c\ -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Michael Enright Sent: Friday, February 10, 2017 3:43 PM To: cygwin@cygwin.com Subject: Re: cygpath On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote: > Sorry, I forgot the user I log in as is switching to cmd.exe. > > This doesn't happen in sh or tcsh, so it is probably a non-issue. > My results are from running a "normal" bash-under-mintty setup. If I go to a cmd.exe window and start bash, Z:\>cygpath -w "/usr/bin/*" C:\cygwin\bin\? Z:\> This is consistent with the explanation that an asterisk ends up having a private-use character substituted in for it. -- 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 -- 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
Re: cygpath
On Fri, Feb 10, 2017 at 12:42 PM, Michael Enright wrote: > On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote: >> Sorry, I forgot the user I log in as is switching to cmd.exe. >> >> This doesn't happen in sh or tcsh, so it is probably a non-issue. >> > > My results are from running a "normal" bash-under-mintty setup. > > If I go to a cmd.exe window and start bash, > Correction. I simply put c:/cygwin/bin on my path I didn't start bash. [redfaced emoji] > Z:\>cygpath -w "/usr/bin/*" > C:\cygwin\bin\? > > Z:\> > The result when I really did go into bash was basically identical (the character rendered as a question mark, which is the expected rendering). -- 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
Re: cygpath
On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote: > Sorry, I forgot the user I log in as is switching to cmd.exe. > > This doesn't happen in sh or tcsh, so it is probably a non-issue. > My results are from running a "normal" bash-under-mintty setup. If I go to a cmd.exe window and start bash, Z:\>cygpath -w "/usr/bin/*" C:\cygwin\bin\? Z:\> This is consistent with the explanation that an asterisk ends up having a private-use character substituted in for it. -- 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
Re: cygpath
On Fri, Feb 10, 2017 at 11:36 AM, Andrey Repin wrote: > Greetings, Gluszczak, Glenn! > >> Isn’t this a defect in cygpath? Looks like memory corruption. > >> %%%cygpath -w /usr/non-existent/* >> C:\cygwin\usr\non-existent\�[W�� > > Looks more like private character space combined with incorrect terminal > setup. The link to private character space is reay obscure. Firstly, the commands that sometimes show failure have a '*' or splat in them. Bash will try to convert a path with a splat in it to the list of matching paths, if there are matches. If there aren't, then the argument seen by the spawned program will contain a splat. Then the cygpath program has to properly describe the path that contains the splat. The splat is not a legal character IN A WINDOWS PATH, but a private character could be and that's how terminal configuration enters in. Cygpath is giving the string that would be used to represent the path, and that string will contain a private use character. In my testing, the environment has no LC variable set to anything, so the locale mechanisms are presumably doing their default things. All my attempts with this got a empty box character at first, if the asterisk went through. That empty box character is presumably some private use character that is supposed to substitute for an asterisk. When I switched mintty's configuration to use Consolas, the previously-run tests output was rerendered by mintty and the 'bad' character rendered as a box with a question mark inside. If I enter cygpath -w /usr/bin/* I get output consisting of all the files in /usr/bin with their paths converted to Windows form. If I escape the argument so globbing is not done, I get the strange output. cygpath -w '/usr/bin/*' C:\cygwin\bin\ In the above the ticks around the path prevented the path from being globbed. It might be considered unexpected though, that the path with an asterisk would be treated as "The user desired to know what the windows path to a file would be if it's cygwin path ended with an asterisk". I think the odds of that user story are vanishingly small compared to the odds of "What would a Windows path to a wildcard look like that corresponds to this Cygwin wildcard?" But that's a design problem. -- 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
RE: cygpath
Sorry, I forgot the user I log in as is switching to cmd.exe. This doesn't happen in sh or tcsh, so it is probably a non-issue. -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Gluszczak, Glenn Sent: Friday, February 10, 2017 3:04 PM To: cygwin@cygwin.com Subject: RE: cygpath * is a legal character for ls but perhaps not cygpath? I don't know. No files or directories are using * in the name. Not sure about incorrect terminal settings as I never touched any. It shows up in mintty and ssh equally. The characters that appear vary. Some non-existent paths do *not* produce the gibberish. %%%cygpath -w /aaa/bbb/* C:\cygwin\aaa\bbb\ -Original Message- From: Andrey Repin [mailto:anrdae...@yandex.ru] Sent: Friday, February 10, 2017 2:36 PM To: Gluszczak, Glenn; cygwin@cygwin.com Subject: Re: cygpath Greetings, Gluszczak, Glenn! > Isn’t this a defect in cygpath? Looks like memory corruption. > %%%cygpath -w /usr/non-existent/* > C:\cygwin\usr\non-existent\�[W�� Looks more like private character space combined with incorrect terminal setup. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars -- With best regards, Andrey Repin Friday, February 10, 2017 22:33:18 Sorry for my terrible english...
RE: cygpath
* is a legal character for ls but perhaps not cygpath? I don't know. No files or directories are using * in the name. Not sure about incorrect terminal settings as I never touched any. It shows up in mintty and ssh equally. The characters that appear vary. Some non-existent paths do *not* produce the gibberish. %%%cygpath -w /aaa/bbb/* C:\cygwin\aaa\bbb\ -Original Message- From: Andrey Repin [mailto:anrdae...@yandex.ru] Sent: Friday, February 10, 2017 2:36 PM To: Gluszczak, Glenn; cygwin@cygwin.com Subject: Re: cygpath Greetings, Gluszczak, Glenn! > Isn’t this a defect in cygpath? Looks like memory corruption. > %%%cygpath -w /usr/non-existent/* > C:\cygwin\usr\non-existent\�[W�� Looks more like private character space combined with incorrect terminal setup. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars -- With best regards, Andrey Repin Friday, February 10, 2017 22:33:18 Sorry for my terrible english...
Re: cygpath
Greetings, Gluszczak, Glenn! > Isn’t this a defect in cygpath? Looks like memory corruption. > %%%cygpath -w /usr/non-existent/* > C:\cygwin\usr\non-existent\�[W�� Looks more like private character space combined with incorrect terminal setup. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars -- With best regards, Andrey Repin Friday, February 10, 2017 22:33:18 Sorry for my terrible english...
Re: cygpath -w converts relative paths to absolute windows paths
Hi Andrey, That was probably true in the past, but no longer! I just tested this: `mklink /D testlink "..\All Users"` in cmd and then I went to Cygwin ZSH, and ran `ll`. This showed me: `testlink -> '../All Users'/`. Up one directory relative links do work on Windows! This is a directory symbolic link, which is superior to directory junctions. Regardless of directory junction support (which I didn't test), I think `cygpath` should give the right results, when I don't specify an absolute path, I really mean give me the windows version of the relative path. Now maybe there's some backwards compatibility issues, then perhaps a flag that can be set to mean `--really-relative`. Thanks, Roger On 8/02/2017 2:30 AM, Andrey Repin wrote: Greetings, Roger Qiu! Hi, I've found that `cygpath --windows '../` will give back an absolute windows path. I thought this would only happen if you provide the `--absolute` flag, or when the path is a special cygwin path. ".." is a special path, that can't be safely converted. In all cases, using absolute path is preferred for many reasons. But this occurs just for normal directories. I have come across a situation where I need to convert ntfs symlinks to unix symlinks and back. Sometimes these symlinks have relative paths them. Now by using cygpath --windows, I get back absolute paths, which means the integrity of the symlink isn't preserved. Can `cygpath --windows '../directory'` give back `..\directory` for paths aren't special cygwin paths? These relative backslashes are supported in Windows right now. AFAIK, Windows do not support relative junction points. -- Founder of Polycademy http://polycademy.com/ +61420925975 -- 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
Re: cygpath -w converts relative paths to absolute windows paths
Hi Andrey, Am 08.02.2017 um 11:54 schrieb Andrey Repin: Greetings, Thomas Wolff! Am 07.02.2017 um 16:30 schrieb Andrey Repin: Greetings, Roger Qiu! I've found that `cygpath --windows '../` will give back an absolute windows path. ... ".." is a special path, that can't be safely converted. How is the special meaning of ".." so much different in Windows than in Cygwin/Linux/POSIX that it could not be mapped? Things like dir .., cd .., type ..\sub\file all work comparably. Comparable? May be. Predictable? https://bugs.php.net/bug.php?id=73797 I don't know what __DIR__ is supposed to mean in PHP. Anyway, handling ".." is not predictable even within Linux/Cygwin, you could see something like: > ls dir1/file dir1/file > cd dir2 > ls ../dir1/file No such file or directory (if dir2 is a link), or can have surprising effects of cd vs. cd -P. I don't see how that should exclude ".." from being transformed to ".." by cygpath -w, even if the result may be somewhat unexpected in some border cases (which I haven't seen yet). -- Thomas -- 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
Re: cygpath -w converts relative paths to absolute windows paths
Greetings, Thomas Wolff! > Am 07.02.2017 um 16:30 schrieb Andrey Repin: >> Greetings, Roger Qiu! >> >>> I've found that `cygpath --windows '../` will give back an absolute windows >>> path. >>> ... >> ".." is a special path, that can't be safely converted. > How is the special meaning of ".." so much different in Windows than in > Cygwin/Linux/POSIX that it could not be mapped? > Things like dir .., cd .., type ..\sub\file all work comparably. Comparable? May be. Predictable? https://bugs.php.net/bug.php?id=73797 -- With best regards, Andrey Repin Wednesday, February 8, 2017 13:53:10 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
Re: cygpath -w converts relative paths to absolute windows paths
On 2017-02-07 16:34, Thomas Wolff wrote: > Am 07.02.2017 um 16:30 schrieb Andrey Repin: >> Greetings, Roger Qiu! >>> I've found that `cygpath --windows '../` will give back an >>> absolute windows path. >>> ... >> ".." is a special path, that can't be safely converted. > How is the special meaning of ".." so much different in Windows than > in Cygwin/Linux/POSIX that it could not be mapped? > Things like dir .., cd .., type ..\sub\file all work comparably. Think the problem is tracking logical directory paths following symlinks makes it difficult to reconstruct a relative Windows directory path - I like and use symlinks a lot as command line accessible shortcuts to directories spread all over the place - and shells that only track physical directory paths used to drive me wild, as cd dir followed by cd .. left me off in the wild. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
Re: cygpath -w converts relative paths to absolute windows paths
Hi Andrey, Am 07.02.2017 um 16:30 schrieb Andrey Repin: Greetings, Roger Qiu! I've found that `cygpath --windows '../` will give back an absolute windows path. ... ".." is a special path, that can't be safely converted. How is the special meaning of ".." so much different in Windows than in Cygwin/Linux/POSIX that it could not be mapped? Things like dir .., cd .., type ..\sub\file all work comparably. -- Thomas -- 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
Re: cygpath -w converts relative paths to absolute windows paths
On 2/7/2017 10:30 AM, Andrey Repin wrote: > Greetings, Roger Qiu! > >> Hi, > >> I've found that `cygpath --windows '../` will give back an absolute >> windows path. > >> I thought this would only happen if you provide the `--absolute` flag, >> or when the path is a special cygwin path. > > ".." is a special path, that can't be safely converted. > In all cases, using absolute path is preferred for many reasons. > May be preferred but the -a --absolute flags tell me that it should be a user choice and not forced on the user. >> But this occurs just for normal directories. > >> I have come across a situation where I need to convert ntfs symlinks to >> unix symlinks and back. Sometimes these symlinks have relative paths >> them. Now by using cygpath --windows, I get back absolute paths, which >> means the integrity of the symlink isn't preserved. > >> Can `cygpath --windows '../directory'` give back `..\directory` for >> paths aren't special cygwin paths? These relative backslashes are >> supported in Windows right now. > > AFAIK, Windows do not support relative junction points. > > But it should be left to the user of the tools to use them with their environment as needed. Getting too cautious to "help" the user with their own environment isn't ideal because there is always someone else that the caution hurts. -- cyg Simple -- 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
Re: cygpath -w converts relative paths to absolute windows paths
Greetings, Roger Qiu! > Hi, > I've found that `cygpath --windows '../` will give back an absolute > windows path. > I thought this would only happen if you provide the `--absolute` flag, > or when the path is a special cygwin path. ".." is a special path, that can't be safely converted. In all cases, using absolute path is preferred for many reasons. > But this occurs just for normal directories. > I have come across a situation where I need to convert ntfs symlinks to > unix symlinks and back. Sometimes these symlinks have relative paths > them. Now by using cygpath --windows, I get back absolute paths, which > means the integrity of the symlink isn't preserved. > Can `cygpath --windows '../directory'` give back `..\directory` for > paths aren't special cygwin paths? These relative backslashes are > supported in Windows right now. AFAIK, Windows do not support relative junction points. -- With best regards, Andrey Repin Tuesday, February 7, 2017 18:27:52 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
Re: cygpath 2.6.0: -m " C:" and garbled output
Just to clarify, " C:" is not the entire filepath I was giving to cygpath, it's more like " C:/Temp/a.txt", but I reduced to it when trying to isolate the difference between versions. On Thu, Oct 6, 2016 at 9:26 PM, Achim Gratz wrote: > A filename can legitimately start with a space and it is a relative filename > in that case. So dropping the space just to get something that looks like a > drive letter is wrong. Indeed! I hadn't thought it that way, and it nicely explains why no conversion happens without the space (in which case it would be considered an absolute file path, despite starting with "C:"). > That's how the otherwise forbidden ":" character gets encoded into the > filename. I do know that ":" is forbidden in a filename, but because I (assumed I) was giving it a file path (and one which was supposed to be absolute), I didn't consider that the rules about special filenames would apply. But having a relative file path changes everything. >> In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:, as I >> would expect. > > No, that's wrong as explained above. I should have said, "as I got used to expect due to past behavior". I would guess those versions were more lenient towards absolute file paths, which would however be an issue for filenames starting with spaces. Thanks to both of you for the clarifications. In the end, the extra whitespace was incorrectly inserted by a makefile function call, so I fixed it anyway, but I wanted to fully understand the issue to avoid incurring into similar problems later. -- 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
Re: cygpath 2.6.0: -m " C:" and garbled output
Andre Maroneze writes: > I just noticed a difference in behavior between versions 2.5.2 and > 2.6.0 of cygpath (the ones I could test): if I run > > cygpath -m " C:" > > (notice the space before the C, inside the double quotes) A filename can legitimately start with a space and it is a relative filename in that case. So dropping the space just to get something that looks like a drive letter is wrong. > In cygpath 2.6.0, this outputs C? (C followed by the unicode character > 0xF03A, which is a ":" (0x3A) character, but prefixed with "F0"). That's how the otherwise forbidden ":" character gets encoded into the filename. > In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:, > as I would expect. No, that's wrong as explained above. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Re: cygpath 2.6.0: -m " C:" and garbled output
On 10/6/2016 8:38 AM, Andre Maroneze wrote: I just noticed a difference in behavior between versions 2.5.2 and 2.6.0 of cygpath (the ones I could test): if I run cygpath -m " C:" (notice the space before the C, inside the double quotes) In cygpath 2.6.0, this outputs C? (C followed by the unicode character 0xF03A, which is a ":" (0x3A) character, but prefixed with "F0"). In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:, as I would expect. This happens on both Windows 7 and Windows 8.1, and not only on my machine, so it seems fairly deterministic. Is it some sort of undefined behavior to give an argument to cygpath starting with a space inside double quotes? I think you'll find the explanation here: https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars I don't know why this doesn't happen with earlier versions of cygwin. Ken -- 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
Re: cygpath -w and .exe magic
On 8/26/2016 10:58 AM, Nellis, Kenneth wrote: > $ cmd /c DIR $(cygpath -w hello) But $ cmd /c $(cygpath -w hello) will execute hello.exe The fact that you get file not found error tells me that cmd is doing what it does. The purpose of the .exe magic is for executing the file from the Cygwin shell. My opinion is that we shouldn't rely on the .exe magic; there are hidden dangers and some use those dangers to a benefit. -- cyg Simple -- 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
Re: cygpath -w and .exe magic
On Fri, Aug 26, 2016 at 10:58 AM, Nellis, Kenneth wrote: > Here is a contrived example: > > $ cmd /c DIR $(cygpath -w hello.exe) > Volume in drive C has no label. > Volume Serial Number is 6A15-FFB2 > > Directory of C:\cygwin\home\knellis\dev\c\hello > > 08/26/2016 10:4760,927 hello.exe >1 File(s) 60,927 bytes >0 Dir(s) 218,673,360,896 bytes free > $ cmd /c DIR $(cygpath -w hello) > Volume in drive C has no label. > Volume Serial Number is 6A15-FFB2 > > Directory of C:\cygwin\home\knellis\dev\c\hello > > File Not Found > $ That isn't really a failure, as "dir foo" in CMD.EXE should (and does) return file not found if file "foo" (no extension) does not exist. -- Erik -- 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
Re: cygpath -w and .exe magic
On 26.08.2016 15:08, Nellis, Kenneth wrote: Dear Cygwin Community, $ ls -l total 60 -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe $ ./hello Hello, world! $ cygpath -w hello hello $ The purpose of cygpath -w, it seems to me, is to provide to Windows a valid path given a Posix path. Given executable file foo.exe, which Cygwin allows to be referenced simply as foo, should not: cygpath -w foo return: foo.exe instead of: foo ? Passing foo to a Windows application will certainly be a problem. I recognize this might be considered a change of scope for the program, but I think the tool should do the .exe magic rather than pass off this responsibility to the user. Food for thought. Sounds reasonable, but why shouldn't one have to say .exe if they mean .exe? That principle makes things easy. Just to illustrate a complication of that approach: Imagine you want to tell a program to safe its data to file foo and cygpath sees that there is a file Foo.exe, it will make the Windows program overwrite Foo.exe instead. And as far as i understand, the reason why Cygwin added this automatic addition of .exe is not to safe the user 4 key strokes, but because some programs cannot live without it - i remember Corinna saying that one cannot run Cygwin programs from cmd.exe if they don't have the .exe appended - and requiring to specify the exact name of an executable, i.e. with the .exe would break each and every script or executable that were written with only POSIX in mind. They say cp or bash, but not cp.exe or bash.exe . So Cygwin did this not to make it easy for users, but out of a dilemma: make Cygwin executables available to the Windows world vs. not breaking all POSIX programs. And if you use cygpath, you are writing code for the Windows environment, and then you can add the .exe where its needed i think. best regards, Herbert Stocker --Ken Nellis -- 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 -- 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
RE: cygpath -w and .exe magic
From: cyg Simple > On 8/26/2016 10:35 AM, Nellis, Kenneth wrote: > > From: Herbert Stocker > >> On 26.08.2016 15:19, Lee Dilkie wrote: > >>> and break everyone who has existing code to take care of this? > >> > >> If it is done, it should be done as an additional option, i'd say. > > > > Of course a new option, duh! ☺ > > But my feeble brain is failing to imagine a case where this > > would break anything, unless the user solution would turn > > a returned foo.exe into foo.exe.exe, which seems doubtful. > > > > We still don't have a valid case of failure without the .exe. Until > that happens this is a no-go change. Here is a contrived example: $ cmd /c DIR $(cygpath -w hello.exe) Volume in drive C has no label. Volume Serial Number is 6A15-FFB2 Directory of C:\cygwin\home\knellis\dev\c\hello 08/26/2016 10:4760,927 hello.exe 1 File(s) 60,927 bytes 0 Dir(s) 218,673,360,896 bytes free $ cmd /c DIR $(cygpath -w hello) Volume in drive C has no label. Volume Serial Number is 6A15-FFB2 Directory of C:\cygwin\home\knellis\dev\c\hello File Not Found $ As I originally said, "Food for thought." I thought it might be worth a discussion. Appreciate the comments. --Ken Nellis
Re: cygpath -w and .exe magic
On 26 August 2016 at 07:08, Nellis, Kenneth wrote: > Dear Cygwin Community, > > $ ls -l > total 60 > -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe > $ ./hello > Hello, world! > $ cygpath -w hello > hello > $ > > The purpose of cygpath -w, it seems to me, is to provide > to Windows a valid path given a Posix path. > There is no requirement that the any part of the path presented to cygpath actually exists. Otherwise, you would not be able to pass the name of a non-existent file or directory to a windows only program that only understands strictly windows paths. To do what you want, cygpath would need two new options. One to specify that the path represents an existing filesystem object, and a second to specify that the path represents an executable file. Both of those options would require cygpath to inspect the file system, rather than current operations which return path format transformations or static information. Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
Re: cygpath -w and .exe magic
On 8/26/2016 10:35 AM, Nellis, Kenneth wrote: > From: Herbert Stocker >> On 26.08.2016 15:19, Lee Dilkie wrote: >>> and break everyone who has existing code to take care of this? >> >> If it is done, it should be done as an additional option, i'd say. > > Of course a new option, duh! ☺ > But my feeble brain is failing to imagine a case where this > would break anything, unless the user solution would turn > a returned foo.exe into foo.exe.exe, which seems doubtful. > We still don't have a valid case of failure without the .exe. Until that happens this is a no-go change. -- cyg Simple -- 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
RE: cygpath -w and .exe magic
From: Herbert Stocker > On 26.08.2016 15:19, Lee Dilkie wrote: > > and break everyone who has existing code to take care of this? > > If it is done, it should be done as an additional option, i'd say. Of course a new option, duh! ☺ But my feeble brain is failing to imagine a case where this would break anything, unless the user solution would turn a returned foo.exe into foo.exe.exe, which seems doubtful. --Ken Nellis
Re: cygpath -w and .exe magic
On 8/26/2016 9:08 AM, Nellis, Kenneth wrote: > Dear Cygwin Community, > > $ ls -l > total 60 > -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe > $ ./hello > Hello, world! > $ cygpath -w hello > hello > $ > > The purpose of cygpath -w, it seems to me, is to provide > to Windows a valid path given a Posix path. > > Given executable file foo.exe, which Cygwin allows to be > referenced simply as foo, should not: cygpath -w foo > return: foo.exe > instead of: foo > ? > > Passing foo to a Windows application will certainly > be a problem. I recognize this might be considered a > change of scope for the program, but I think the tool > should do the .exe magic rather than pass off this > responsibility to the user. Food for thought. You say certainly but provide no real proof other than your assumptions. Cygpath has been performing for many years without anyone complaining about the missing .exe. I don't think we need to change it. -- cyg Simple -- 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
Re: cygpath -w and .exe magic
On 26.08.2016 15:19, Lee Dilkie wrote: On 8/26/2016 9:08 AM, Nellis, Kenneth wrote: Dear Cygwin Community, $ ls -l total 60 -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe $ ./hello Hello, world! $ cygpath -w hello hello $ The purpose of cygpath -w, it seems to me, is to provide to Windows a valid path given a Posix path. Given executable file foo.exe, which Cygwin allows to be referenced simply as foo, should not: cygpath -w foo return: foo.exe instead of: foo ? Passing foo to a Windows application will certainly be a problem. I recognize this might be considered a change of scope for the program, but I think the tool should do the .exe magic rather than pass off this responsibility to the user. Food for thought. and break everyone who has existing code to take care of this? If it is done, it should be done as an additional option, i'd say. Herbert -- 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 -- 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
