Re: Incorrect results from 'cygpath -w' when having anaconda installed
Greetings, enri...@perezterron.net! > Hello! > I am having incorrect results from 'cygpath -w': > ### I have the cygwin root directory in C:\cygwin64, as confirmed by 'cmd': > $ cmd > Microsoft Windows [Version 10.0.22621.674] > (c) Microsoft Corporation. Med enerett. > C:\cygwin64\home\Enrique>exit > ### Cygwin thinks my home directory is: > $ pwd > /home/Enrique > ### But 'cygpath -w' thinks ... > $ cygpath -w /home/Enrique > C:\Users\Enrique\anaconda3\Library\home\Enrique > ### Investigating, I found that there is no 'home' in > C:\Users\Enrique\anaconda3\Library. > ### Then I discovered this: > $ mount > C:/Users/Enrique/anaconda3/Library on / type ntfs (binary,noacl,auto) > C:/Users/Enrique/anaconda3/Library/usr/bin on /bin type ntfs > (binary,noacl,auto) > C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) > Huh ??? How does this work? > Is there a way to hide the mounts done by anaconda? > I guess some anaconda binaries want to find the 'Library' directory as the > root, but cygwin continues to find its own root under C:/cygwin64. Why does > it get tripped by the anaconda install just when doing the path translation? Either you have two Cygwin version sinstalled, or your environment is screwed. Please provide cygcheck output per https://cygwin.com/problems.html -- With best regards, Andrey Repin Sunday, November 6, 2022 18:19:37 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
Incorrect results from 'cygpath -w' when having anaconda installed
Hello! I am having incorrect results from 'cygpath -w': ### I have the cygwin root directory in C:\cygwin64, as confirmed by 'cmd': $ cmd Microsoft Windows [Version 10.0.22621.674] (c) Microsoft Corporation. Med enerett. C:\cygwin64\home\Enrique>exit ### Cygwin thinks my home directory is: $ pwd /home/Enrique ### But 'cygpath -w' thinks ... $ cygpath -w /home/Enrique C:\Users\Enrique\anaconda3\Library\home\Enrique ### Investigating, I found that there is no 'home' in C:\Users\Enrique\anaconda3\Library. ### Then I discovered this: $ mount C:/Users/Enrique/anaconda3/Library on / type ntfs (binary,noacl,auto) C:/Users/Enrique/anaconda3/Library/usr/bin on /bin type ntfs (binary,noacl,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) Huh ??? How does this work? Is there a way to hide the mounts done by anaconda? I guess some anaconda binaries want to find the 'Library' directory as the root, but cygwin continues to find its own root under C:/cygwin64. Why does it get tripped by the anaconda install just when doing the path translation? -Enrique -- 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
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
cygpath 3.3.4 : incorrect windows to unix path conversions
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 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!) 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! 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. We are seeing variations of this, on multiple systems (Windows 10, 11, 2016 datacenter). The paths sometimes get partially translated, like this: DBG: 'E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug\\cygpath.exe E:\\': 0 '/cygdrive/e/\n' DBG: 'E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug\\cygpath.exe E:\\SteamLibrary': 0 '/cygdrive/e/SteamLibrary\n' DBG: 'E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug\\cygpath.exe E:\\SteamLibrary\\steamapps': 0 '/cygdrive/e/SteamLibrary/steamapps\n' DBG: 'E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug\\cygpath.exe E:\\SteamLibrary\\steamapps\\common': 0 '/\n' DBG: 'E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug\\cygpath.exe E:\\SteamLibrary\\steamapps\\common\\SteamOSDevkitClient-Debug': 0 '/SteamOSDevkitClient-Debug\n' 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. Cheers, - TTimo cygcheck.out Description: Binary data -- 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
cygpath gives no output, cygwin 3.3.4
Hi all, We've had issues at work with our Cygwin environment recently. Historically we've used an older 32-bit version of Cygwin that stopped working for newer laptops, which led us do a fresh install of the latest 64-bit 3.3.4 Cygwin. So far everything seems o be working except for cygpath, which gives us no ouput. Our build environment is heavily dependent on cygpath and is now unable to build in windows. Building from native Linux works fine. I've googled lots without any progress. Found this very old thread which suggested installing libgcc++-6, that did not work for me https://cygwin.com/pipermail/cygwin/2009-November/180956.html I've attached the output of cygcheck, with a few lines removed which might be sensitive information. As you can see I have quite a few different installs of Cygwin that I've played around with. It's the cygwin64 folder which I am using here, and the only one included in windows Path. Any help is highly appreciated! Best regards, Daniel Krumlinde cygcheck.out Description: cygcheck.out -- 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
cygpath not doing anything on a fresh install
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? Thanks 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: Misbehaviour of cygpath -am between versions 3.1.4 and 3.3.2
On Nov 17 19:44, Andrey Repin via Cygwin wrote: > Greetings, Wolfgang S. Kechel! > > > The command 'cygpath -am .' yields different results between > > cygwin-3.1.4-1 and cygwin-3.3.2-1 on a Windows 10 box when the current > > directory is a network share. > > > Example with V3.1.4: > > > cygpath -am . ---> P:/mytool/gbuild/wintel/libtiff > > > Example with V3.3.2-1 > > > cygpath -am . ---> //mynas.mydomain.de/product/mytool/gbuild/wintel/libtiff > > I'm pretty sure there was a discussion about it earlier. > > > This causes UNC filenames to appear and this cmd.exe is unable to start > > in those directories when started from a cygwin shell or from nmake run > > in a cygwin shell. > > cmd.exe can be configured to STFU. Apparently default starting with Windows 11... 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: Misbehaviour of cygpath -am between versions 3.1.4 and 3.3.2
Greetings, Wolfgang S. Kechel! > The command 'cygpath -am .' yields different results between > cygwin-3.1.4-1 and cygwin-3.3.2-1 on a Windows 10 box when the current > directory is a network share. > Example with V3.1.4: > cygpath -am . ---> P:/mytool/gbuild/wintel/libtiff > Example with V3.3.2-1 > cygpath -am . ---> //mynas.mydomain.de/product/mytool/gbuild/wintel/libtiff I'm pretty sure there was a discussion about it earlier. > This causes UNC filenames to appear and this cmd.exe is unable to start > in those directories when started from a cygwin shell or from nmake run > in a cygwin shell. cmd.exe can be configured to STFU. >> $ cd $( cygpath -am . ) >> >> $ cmd /C DIR . >> Volume in drive \\DAEMON1\anrdaemon is anrdaemon >> Volume Serial Number is 3D5A-4F9A >> >> Directory of \\DAEMON1\anrdaemon\Documents\_ps1 >> >> 22.07.2020 10:23 . >> 27.07.2021 19:21 .. >> 28.08.2019 14:25 HTML5Video >> 22.03.2020 00:22 Maintenance >> 22.03.2020 00:2388 wmi.btm >> 29.08.2018 18:14 1 871 dl-files.cmd >> 01.09.2019 18:01 194 ats.sh >>3 File(s) 2 153 bytes >>4 Dir(s) 361 313 710 080 bytes free >> >> $ > I prefer to get the old behaviour back since it worked for 20+ years up > to now - or at least an option to enable the old behavior again. The option is in https://ss64.com/nt/syntax-cmd.html (Original article from web archive: https://web.archive.org/web/20150312195558/https://support.microsoft.com/en-us/kb/156276 ) > Please note that I have not subscribed to any cygwin mailing list. Noted… -- With best regards, Andrey Repin Wednesday, November 17, 2021 19:36:02 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
Misbehaviour of cygpath -am between versions 3.1.4 and 3.3.2
Dear folks! The command 'cygpath -am .' yields different results between cygwin-3.1.4-1 and cygwin-3.3.2-1 on a Windows 10 box when the current directory is a network share. Example with V3.1.4: cygpath -am . ---> P:/mytool/gbuild/wintel/libtiff Example with V3.3.2-1 cygpath -am . ---> //mynas.mydomain.de/product/mytool/gbuild/wintel/libtiff This causes UNC filenames to appear and this cmd.exe is unable to start in those directories when started from a cygwin shell or from nmake run in a cygwin shell. I prefer to get the old behaviour back since it worked for 20+ years up to now - or at least an option to enable the old behavior again. Please note that I have not subscribed to any cygwin mailing list. Thanks in advance and best regards Wolfgang -- Wolfgang Kechel mailto:wolfgang.kec...@prs.de Patzschke + Rasp Software GmbH http://www.prs.de Bierstadter Straße 7 Fax: +49-(0)611-1731-31 D-65189 Wiesbaden Phone: +49-(0)611-1731-611 / +49-(0)174-3454260 Patzschke + Rasp Software GmbH, Bierstadter Str. 7, D-65189 Wiesbaden Eintragung im Handelsregister: Amtsgericht Wiesbaden, HRB Nr. 22673 Geschäftsführer: Wolfgang Kechel, Till Immanuel Patzschke -- 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
cygpath and star character
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 0 >cygpath -wp "./*/*" <-- but this works as expected *\* Is this bug or expected behavior ? Pls, answer to me in To:, I'm not a permanent member of the cygwin email list. I found it during assembly of the Java CLASSPATH variable, which may contain the "*" character at the end to cover all .jar in the specified directory. Tomas -- 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
cygpath -w space becomes line breaks?
Hi, Is this intended or am I misconfiguring something? penguin@MY-PC~/Documents/Visual Studio 2015/Projects $ cygpath -w `pwd` D:\penguin\Documents\Visual Studio 2015\Projects penguin@MY-PC~/Documents/Visual Studio 2015/Projects $ cygpath -w `pwd` | xxd : 443a 5c70 656e 6775 696e 5c44 6f63 756d D:\penguin\Docum 0010: 656e 7473 5c56 6973 7561 6c0a 5374 7564 ents\Visual.Stud 0020: 696f 0a32 3031 355c 5072 6f6a 6563 7473 io.2015\Projects 0030: 0a . As you can see the dir "Visual Studio 2015" being broken into lines. -- 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
How to get the drive a file is on (was Re: /bin/pwd, cygpath -wa fail under native symlink)
I need to find out the drive on which some files reside. I need to make some links from a tmp dir to the files from a script. So I need to determine where they reside so I can figure out which tmp dir to use. Hard links, not running as administrator. I tried cygpath -wa and /bin/pwd. They fail in some cases as described below. If this is a problem for cygwin, is there a win7 command I can use? -ernie On 12/25/2019 2:05 PM, Ernie Rael wrote: (CYGWIN_NT-6.1 spirit 3.1.1(0.340/5/3) 2019-12-18 09:28 x86_64 Cygwin, win7) The windows root is C:, cygwin root is on F:. A native symlink under C: that points into F: gets an incorrect result from cygpath -wa. Notice that when the current directory is the target of the symlink then the result is ok. But any deeper in the tree fails. To summarize: @ /a/src/jvi-dev/jvi $ cygpath -wa . C:\f\src\jvi-dev\jvi <<<<<<< correct @ /a/src/jvi-dev/jvi/src $ cygpath -wa . C:\a\src\jvi-dev\jvi\src <<<<<<< fail === more detail === @ /a/src/jvi-dev $ ls -l jvi lrwxrwxrwx 1 erra None 18 Dec 23 15:16 jvi -> /f/src/jvi-dev/jvi @ /a/src/jvi-dev $ junction jvi Junction v1.06 - Windows junction creator and reparse point viewer Copyright (C) 2000-2010 Mark Russinovich Sysinternals - www.sysinternals.com C:\a\src\jvi-dev\jvi: SYMBOLIC LINK Print Name : C:\f\src\jvi-dev\jvi Substitute Name: \??\C:\f\src\jvi-dev\jvi @ /a/src/jvi-dev $ cygpath -wa jvi C:\a\src\jvi-dev\jvi @ /a/src/jvi-dev $ cd jvi @ /a/src/jvi-dev/jvi $ cygpath -wa . C:\f\src\jvi-dev\jvi <<<<<<< correct @ /a/src/jvi-dev/jvi $ cd src @ /a/src/jvi-dev/jvi/src $ cygpath -wa . C:\a\src\jvi-dev\jvi\src <<<<<<< fail === some possibly relevent stuff from the mount table $ mount F:/cygwin64 on / type ntfs (binary,auto) C:/f on /f type ntfs (binary,user) F:/c on /c type ntfs (binary,user) F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto) -- 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
/bin/pwd, cygpath -wa fail under native symlink
(CYGWIN_NT-6.1 spirit 3.1.1(0.340/5/3) 2019-12-18 09:28 x86_64 Cygwin, win7) The windows root is C:, cygwin root is on F:. A native symlink under C: that points into F: gets an incorrect result from cygpath -wa. Notice that when the current directory is the target of the symlink then the result is ok. But any deeper in the tree fails. To summarize: @ /a/src/jvi-dev/jvi $ cygpath -wa . C:\f\src\jvi-dev\jvi <<<<<<< correct @ /a/src/jvi-dev/jvi/src $ cygpath -wa . C:\a\src\jvi-dev\jvi\src <<<<<<< fail === more detail === @ /a/src/jvi-dev $ ls -l jvi lrwxrwxrwx 1 erra None 18 Dec 23 15:16 jvi -> /f/src/jvi-dev/jvi @ /a/src/jvi-dev $ junction jvi Junction v1.06 - Windows junction creator and reparse point viewer Copyright (C) 2000-2010 Mark Russinovich Sysinternals - www.sysinternals.com C:\a\src\jvi-dev\jvi: SYMBOLIC LINK Print Name : C:\f\src\jvi-dev\jvi Substitute Name: \??\C:\f\src\jvi-dev\jvi @ /a/src/jvi-dev $ cygpath -wa jvi C:\a\src\jvi-dev\jvi @ /a/src/jvi-dev $ cd jvi @ /a/src/jvi-dev/jvi $ cygpath -wa . C:\f\src\jvi-dev\jvi <<<<<<< correct @ /a/src/jvi-dev/jvi $ cd src @ /a/src/jvi-dev/jvi/src $ cygpath -wa . C:\a\src\jvi-dev\jvi\src <<<<<<< fail === some possibly relevent stuff from the mount table $ mount F:/cygwin64 on / type ntfs (binary,auto) C:/f on /f type ntfs (binary,user) F:/c on /c type ntfs (binary,user) F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto) -- 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: Unexpected behavior from cygpath command
Greetings, Lee! >>> I think on both systems the handling of 8.3 names is configured >>> differently. You can check this with the Window command fsutil. (This >>> command requires elevated permissions) >>> >>> I get the following output on my system. >>> >>> C:\WINDOWS\system32>fsutil 8dot3name query d: >>> The volume state is: 0 (8dot3 name creation is enabled). >>> The registry state is: 2 (Per volume setting - the default). >> >> Thanks, I think this is very interesting, I did not know that such a setting >> existed. It was indeed disabled for my E: drive. However, after enabling >> it I still can’t get “cygpath -d" to work as expected. > Do the 8.3 names exist? > dir E:\ /n /x > ..wondering if you have to recreate the file names to get “cygpath -d" to work Wondering, why anybody would use 8.3 names in XXI century. I've consciously disabled creation of 8.3 names for all but system volumes on all systems in my reach, and never had to look back. But if you absolutely must… fsutil file setshortname Do note that such name can be literally anything. This is primary reason I disable them. To reduce amount of confusion in my daily routine. -- With best regards, Andrey Repin Monday, November 18, 2019 0:00:42 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: Unexpected behavior from cygpath command
On 11/13/19, Alfred von Campe wrote: > On Nov 13, 2019, at 2:08, Frank Redeker wrote: > >> I think on both systems the handling of 8.3 names is configured >> differently. You can check this with the Window command fsutil. (This >> command requires elevated permissions) >> >> I get the following output on my system. >> >> C:\WINDOWS\system32>fsutil 8dot3name query d: >> The volume state is: 0 (8dot3 name creation is enabled). >> The registry state is: 2 (Per volume setting - the default). > > Thanks, I think this is very interesting, I did not know that such a setting > existed. It was indeed disabled for my E: drive. However, after enabling > it I still can’t get “cygpath -d" to work as expected. Do the 8.3 names exist? dir E:\ /n /x ..wondering if you have to recreate the file names to get “cygpath -d" to work -- 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: Unexpected behavior from cygpath command
On 2019-11-13 11:29, Alfred von Campe wrote: > On Nov 13, 2019, at 2:08, Frank Redeker wrote: > >> I think on both systems the handling of 8.3 names is configured >> differently. You can check this with the Window command fsutil. (This >> command requires elevated permissions) >> >> I get the following output on my system. >> >> C:\WINDOWS\system32>fsutil 8dot3name query d: >> The volume state is: 0 (8dot3 name creation is enabled). >> The registry state is: 2 (Per volume setting - the default). > > Thanks, I think this is very interesting, I did not know that such a setting > existed. It was indeed disabled for my E: drive. However, after enabling it > I still can’t get “cygpath -d" to work as expected. This setting also doesn’t > explain why cygpath returns the correct DOS path when I pass it in a Unix > style path instead of a Windows style path. I have found that there is something different about cygpath that behaves less consistently when used between `backquotes` than $(command quotes). Have you tried forcing short names with -s, --short-name: -ds or -ws to see if those help? If those don't, try adding -a, --absolute: -ads -aws to see if that makes a difference. Check the drive file system from an elevated command prompt, and save the output, reboot, recheck, compare the output to see if anything differs, and retest, to see if anything changes: > fsutil fsinfo drivetype e: e: - Fixed Drive > fsutil fsinfo volumeinfo e: Volume Name : ... Volume Serial Number : 0x6b8d438 Max Component Length : 255 File System Name : NTFS Is ReadWrite Not Thinly-Provisioned Supports Case-sensitive filenames Preserves Case of filenames Supports Unicode in filenames Preserves & Enforces ACL's Supports file-based Compression Supports Disk Quotas Supports Sparse files Supports Reparse Points Returns Handle Close Result Information Supports POSIX-style Unlink and Rename Supports Object Identifiers Supports Encrypted File System Supports Named Streams Supports Transactions Supports Hard Links Supports Extended Attributes Supports Open By FileID Supports USN Journal > fsutil fsinfo ntfsinfo e: NTFS Volume Serial Number :0x80ffb5d906b8d438 NTFS Version : 3.1 LFS Version: 2.0 Number Sectors : 0x744bc466 Total Clusters : 0x0e89788c Free Clusters : 0x09817c24 Total Reserved : 0x8bf7 Bytes Per Sector :512 Bytes Per Physical Sector :4096 Bytes Per Cluster :4096 Bytes Per FileRecord Segment: 1024 Clusters Per FileRecord Segment : 0 Mft Valid Data Length :0xef64 Mft Start Lcn : 0x000ad74c Mft2 Start Lcn : 0x0002 Mft Zone Start : 0x05f1ef40 Mft Zone End : 0x05f28fc0 Max Device Trim Extent Count : 0 Max Device Trim Byte Count : 0x0 Max Volume Trim Extent Count : 62 Max Volume Trim Byte Count : 0x4000 Resource Manager Identifier : 99B60DE5-842F-11E1-98AF-D71846560B56 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Unexpected behavior from cygpath command
On Nov 13, 2019, at 2:08, Frank Redeker wrote: > I think on both systems the handling of 8.3 names is configured > differently. You can check this with the Window command fsutil. (This > command requires elevated permissions) > > I get the following output on my system. > > C:\WINDOWS\system32>fsutil 8dot3name query d: > The volume state is: 0 (8dot3 name creation is enabled). > The registry state is: 2 (Per volume setting - the default). Thanks, I think this is very interesting, I did not know that such a setting existed. It was indeed disabled for my E: drive. However, after enabling it I still can’t get “cygpath -d" to work as expected. This setting also doesn’t explain why cygpath returns the correct DOS path when I pass it in a Unix style path instead of a Windows style path. Alfred -- 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: Unexpected behavior from cygpath command
Am 12.11.2019 um 23:16 schrieb Alfred von Campe: > I have two almost identical build servers, but cygpath is not behaving as > expected on one of them. Here is the output from the “good” build server: > > $ cygpath.exe —version | head -1 > cygpath (cygwin) 2.11.2 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\PROGRA~1\IARSYS~1 > > Cygpath has correctly converted the given path to DOS (8.3) format as > expected. Here is the output from the “bad” build server. > > $ cygpath.exe —version | head -1 > cygpath (cygwin) 2.11.1 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\Program Files (x86)\IAR Systems > > Why is cygpath returning the same path passed in? Oh wait, it’s running a > slightly older version (2.11.1 vs 2.11.2). Perhaps there was a bug in the > earlier version. Let me update the Cygwin installation and try again: > > $ cygpath —version | head -1 > cygpath (cygwin) 3.1.0 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\Program Files (x86)\IAR Systems > > WTF? Why is it still doing this? Can there be a global config setting that > affects cygpath’s behavior? Hmm, let me try a different approach: > > $ cygpath -d "$(cygpath -u 'E:\Program Files (x86)\IAR Systems')" > E:\PROGRA~1\IARSYS~1 > > Hey, cygpath can convert to DOS paths on this system after all, just not when > it’s given a Windows path. Can anyone explain this behavior? > > Alfred Hello, Alfred, I think on both systems the handling of 8.3 names is configured differently. You can check this with the Window command fsutil. (This command requires elevated permissions) I get the following output on my system. C:\WINDOWS\system32>fsutil 8dot3name query d: The volume state is: 0 (8dot3 name creation is enabled). The registry state is: 2 (Per volume setting - the default). Based on the above settings, 8dot3 name creation is enabled on d: You can also change the handling of 8.3 names using this command. See flsutil 8dot3name help C:\WINDOWS\system32>fsutil 8dot3name help 8DOT3NAME Commands Supported query Query the current setting for the shortname behaviour on the system scanScan for impacted registry entries set Change the setting that controls the shortname behavior on the system strip Remove the shortnames for all files within a directory Greetings Frank -- 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
Unexpected behavior from cygpath command
I have two almost identical build servers, but cygpath is not behaving as expected on one of them. Here is the output from the “good” build server: $ cygpath.exe —version | head -1 cygpath (cygwin) 2.11.2 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\PROGRA~1\IARSYS~1 Cygpath has correctly converted the given path to DOS (8.3) format as expected. Here is the output from the “bad” build server. $ cygpath.exe —version | head -1 cygpath (cygwin) 2.11.1 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\Program Files (x86)\IAR Systems Why is cygpath returning the same path passed in? Oh wait, it’s running a slightly older version (2.11.1 vs 2.11.2). Perhaps there was a bug in the earlier version. Let me update the Cygwin installation and try again: $ cygpath —version | head -1 cygpath (cygwin) 3.1.0 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\Program Files (x86)\IAR Systems WTF? Why is it still doing this? Can there be a global config setting that affects cygpath’s behavior? Hmm, let me try a different approach: $ cygpath -d "$(cygpath -u 'E:\Program Files (x86)\IAR Systems')" E:\PROGRA~1\IARSYS~1 Hey, cygpath can convert to DOS paths on this system after all, just not when it’s given a Windows path. Can anyone explain this behavior? Alfred -- 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
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
cygpath -u converts quoted UNC paths to local
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 $ -- With best regards, Andrey Repin Wednesday, April 3, 2019 19:11:14 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: error in "cygpath" behavior
Am 31.08.2018 um 22:05 schrieb Eric Blake: On 08/31/2018 02:48 PM, cyg Simple wrote: Don't forget the possibility that '..' points to a symlink which Windows will not understand. $ mkdir -p /foo/baz $ ln -s /foo /bar $ cd /bar/baz $ cygpath -w .. Except .. never points to a symlink. It always points to the physical directory that contains the current directory (that is, /foo, not /bar). The shell can maintain a notion of a logical current directory (based on whether you use 'set -P' for physical or 'set +P' for logical; where bash defaults to +P), and in that mode, 'cd ..' behaves logically (acting as though you are now in /bar, rather than actually changing you to /foo). But that still doesn't change the fact that '..' in file name resolution never resolves to a symlink, because the shell is merely rewriting your ".." to avoid passing it on to the syscalls, rather than the syscalls actually knowing about logical mode. As a side-note, this is also the reason that you may be facing apparent inconsistency with path name completion, like `ls ../[TAB]` suggesting you files and directories that do not exist once you run the command. This is not cygwin-specific. --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: error in "cygpath" behavior
On 2018-08-31 16:34, Steven Penny wrote: > On Fri, 31 Aug 2018 10:57:34, Corinna Vinschen wrote: >> Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally >> disagree. The path is always convert to absolute at this point in favor >> of correct output. There's also the additional restriction (though >> not in this case) that relative Windows paths must not be longer than >> MAX_PATH (260) chars. >> I'm certainly open to patches to the underlying cygwin_conv_path >> function to change the Windows path to relative if possible. > I am not understanding - it appears that "dot-dot" (..) is well defined by > POSIX: >> The special filename dot-dot shall refer to the parent directory of its >> predecessor directory. As a special case, in the root directory, dot-dot may >> refer to the root directory itself. > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 > so it would appears that ".." would be an acceptable return value in any case. See Eric Blake's response to other poster. Proc FS entry /proc/self/cwd only links to the current working directory, and may/does? not necessarily reflect the logical or physical path taken by cd to get to the current directory: only the current shell tracks the logical or physical path taken by cd to get to the current directory, and can interpret to which directory .. refers. If /proc/self/cwd tracked all processes' logical or physical paths taken by chdir(2) to get to the current directory, that link might be used to resolve .. unambiguously. Quoting Corinna: "PGA" ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: error in "cygpath" behavior
Steven Penny writes: > I am not understanding - it appears that "dot-dot" (..) is well defined by > POSIX: […] > so it would appears that ".." would be an acceptable return value in any case. Except that you've asked for a Windows path, not POSIX, and you have no idea what Windows' idea of the CWD is once you start using that string with a Windows application. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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: error in "cygpath" behavior
On Fri, 31 Aug 2018 10:57:34, Corinna Vinschen wrote: Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally disagree. The path is always convert to absolute at this point in favor of correct output. There's also the additional restriction (though not in this case) that relative Windows paths must not be longer than MAX_PATH (260) chars. I'm certainly open to patches to the underlying cygwin_conv_path function to change the Windows path to relative if possible. I am not understanding - it appears that "dot-dot" (..) is well defined by POSIX: The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 so it would appears that ".." would be an acceptable return value in any case. -- 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: error in "cygpath" behavior
On 08/31/2018 02:48 PM, cyg Simple wrote: Don't forget the possibility that '..' points to a symlink which Windows will not understand. $ mkdir -p /foo/baz $ ln -s /foo /bar $ cd /bar/baz $ cygpath -w .. Except .. never points to a symlink. It always points to the physical directory that contains the current directory (that is, /foo, not /bar). The shell can maintain a notion of a logical current directory (based on whether you use 'set -P' for physical or 'set +P' for logical; where bash defaults to +P), and in that mode, 'cd ..' behaves logically (acting as though you are now in /bar, rather than actually changing you to /foo). But that still doesn't change the fact that '..' in file name resolution never resolves to a symlink, because the shell is merely rewriting your ".." to avoid passing it on to the syscalls, rather than the syscalls actually knowing about logical mode. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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: error in "cygpath" behavior
On 8/31/2018 4:57 AM, Corinna Vinschen wrote: > On Aug 30 21:37, Steven Penny wrote: >> It is my understanding that given relative input, "cygpath" shall produce >> relative output unless given "-a" option. However I noticed a discrepancy. >> These >> are all correct: >> >>$ cygpath . >>. >> >>$ cygpath .. >>.. >> >>$ cygpath -w . >>. >> >> This is not: >> >>$ cygpath -w .. >>C:\cygwin64\home\ > > Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally > disagree. The path is always convert to absolute at this point in favor > of correct output. There's also the additional restriction (though > not in this case) that relative Windows paths must not be longer than > MAX_PATH (260) chars. > > I'm certainly open to patches to the underlying cygwin_conv_path > function to change the Windows path to relative if possible. Don't forget the possibility that '..' points to a symlink which Windows will not understand. $ mkdir -p /foo/baz $ ln -s /foo /bar $ cd /bar/baz $ cygpath -w .. -- 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: error in "cygpath" behavior
On Aug 30 21:37, Steven Penny wrote: > It is my understanding that given relative input, "cygpath" shall produce > relative output unless given "-a" option. However I noticed a discrepancy. > These > are all correct: > > $ cygpath . >. > >$ cygpath .. >.. > >$ cygpath -w . >. > > This is not: > >$ cygpath -w .. >C:\cygwin64\home\ Long-standing behaviour. ".." in Cygwin and ".." in Windows can totally disagree. The path is always convert to absolute at this point in favor of correct output. There's also the additional restriction (though not in this case) that relative Windows paths must not be longer than MAX_PATH (260) chars. I'm certainly open to patches to the underlying cygwin_conv_path function to change the Windows path to relative if possible. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
error in "cygpath" behavior
It is my understanding that given relative input, "cygpath" shall produce relative output unless given "-a" option. However I noticed a discrepancy. These are all correct: $ cygpath . . $ cygpath .. .. $ cygpath -w . . This is not: $ cygpath -w .. C:\cygwin64\home\ -- 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: 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
cygpath compatiblity break (v2.1 -> v2.7)
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 ``` 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 ``` -- 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 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
cygpath (reprised)
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? $ uname -svr CYGWIN_NT-6.1 2.7.0(0.306/5/3) 2017-02-12 13:18 $ cygpath --version cygpath (cygwin) 2.7.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. $ --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
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