Re: Incorrect results from 'cygpath -w' when having anaconda installed

[Andrey Repin]

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

[enrique]

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

[Timothee Besset]

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

[Doug Henderson]

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

[Takashi Yano]

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

[Andrey Repin]

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

[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

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

[Antonio Petrelli]

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

[Daniel Krumlinde Lundvall via Cygwin]

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

[Marco Atzeri]

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

[Antonio Petrelli]

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

[Ken Brown]

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

[Antonio Petrelli]

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

[marco atzeri]

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

[Antonio Petrelli]

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

[marco atzeri]

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

[Antonio Petrelli]

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

[Andrey Repin]

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

[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?

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

[Corinna Vinschen via Cygwin]

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

[Andrey Repin via Cygwin]

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

[Wolfgang S. Kechel via Cygwin]

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

[Corinna Vinschen via Cygwin]

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

[Sam Edge via Cygwin]

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

[Tomas Jura via Cygwin]

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

[Ken Brown via Cygwin]

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
0000010

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

[Tomas Jura via Cygwin]

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

[PATCH 1/2] Unpick cygpath TESTSUITE

[Jon Turney]

Rather than having testsuite.h do various things, depending on defines,
just have it do one thing, and then explicitly redirect to test stubs in
path.cc when building test.
---
 winsup/utils/path.cc  | 31 +--
 winsup/utils/path.h   | 10 --
 winsup/utils/testsuite.cc | 31 ---
 winsup/utils/testsuite.h  | 34 +++---
 4 files changed, 48 insertions(+), 58 deletions(-)

diff --git a/winsup/utils/path.cc b/winsup/utils/path.cc
index 29344be02..0d41a45d8 100644
--- a/winsup/utils/path.cc
+++ b/winsup/utils/path.cc
@@ -25,7 +25,6 @@ details. */
 #include "../cygwin/include/sys/mount.h"
 #define _NOMNTENT_MACROS
 #include "../cygwin/include/mntent.h"
-#include "testsuite.h"
 #ifdef FSTAB_ONLY
 #include 
 #endif
@@ -255,14 +254,8 @@ readlink (HANDLE fh, char *path, size_t maxlen)
 }
 #endif /* !FSTAB_ONLY */
 
-#ifndef TESTSUITE
 mnt_t mount_table[255];
 int max_mount_entry;
-#else
-#  define TESTSUITE_MOUNT_TABLE
-#  include "testsuite.h"
-#  undef TESTSUITE_MOUNT_TABLE
-#endif
 
 inline void
 unconvert_slashes (char* name)
@@ -271,9 +264,6 @@ unconvert_slashes (char* name)
 *name++ = '\\';
 }
 
-/* These functions aren't called when defined(TESTSUITE) which results
-   in a compiler warning.  */
-#ifndef TESTSUITE
 inline char *
 skip_ws (char *in)
 {
@@ -555,11 +545,8 @@ from_fstab (bool user, PWCHAR path, PWCHAR path_end)
   CloseHandle (h);
 }
 #endif /* !FSTAB_ONLY */
-#endif /* !TESTSUITE */
 
 #ifndef FSTAB_ONLY
-
-#ifndef TESTSUITE
 static int
 mnt_sort (const void *a, const void *b)
 {
@@ -653,7 +640,11 @@ read_mounts ()
   from_fstab (true, path, path_end);
   qsort (mount_table, max_mount_entry, sizeof (mnt_t), mnt_sort);
 }
-#endif /* !defined(TESTSUITE) */
+
+#ifdef TESTSUITE
+#define read_mounts testsuite_read_mounts
+#endif
+
 
 /* Return non-zero if PATH1 is a prefix of PATH2.
Both are assumed to be of the same path style and / vs \ usage.
@@ -757,6 +748,11 @@ concat (const char *s, ...)
   return vconcat (s, v);
 }
 
+#ifdef TESTSUITE
+#undef GetCurrentDirectory
+#define GetCurrentDirectory testsuite_getcwd
+#endif
+
 /* This is a helper function for when vcygpath is passed what appears
to be a relative POSIX path.  We take a Win32 CWD (either as specified
in 'cwd' or as retrieved with GetCurrentDirectory() if 'cwd' is NULL)
@@ -822,10 +818,9 @@ vcygpath (const char *cwd, const char *s, va_list v)
   size_t max_len = 0;
   mnt_t *m, *match = NULL;
 
-#ifndef TESTSUITE
   if (!max_mount_entry)
 read_mounts ();
-#endif
+
   char *path;
   if (s[0] == '.' && isslash (s[1]))
 s += 2;
@@ -912,10 +907,10 @@ extern "C" FILE *
 setmntent (const char *, const char *)
 {
   m = mount_table;
-#ifndef TESTSUITE
+
   if (!max_mount_entry)
 read_mounts ();
-#endif
+
   return NULL;
 }
 
diff --git a/winsup/utils/path.h b/winsup/utils/path.h
index a1840a003..c64f6ebfb 100644
--- a/winsup/utils/path.h
+++ b/winsup/utils/path.h
@@ -6,6 +6,9 @@ This software is a copyrighted work licensed under the terms of 
the
 Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
 details. */
 
+#ifndef _PATH_H_
+#define _PATH_H_
+
 struct mnt_t
 {
   char *native;
@@ -22,11 +25,14 @@ int get_word (HANDLE, int);
 int get_dword (HANDLE, int);
 bool from_fstab_line (mnt_t *m, char *line, bool user);
 
-#ifndef TESTSUITE
 extern mnt_t mount_table[255];
 extern int max_mount_entry;
-#endif
 
 #ifndef SYMLINK_MAX
 #define SYMLINK_MAX 4095  /* PATH_MAX - 1 */
 #endif
+
+DWORD testsuite_getcwd (DWORD nBufferLength, LPSTR lpBuffer);
+void testsuite_read_mounts (void);
+
+#endif
diff --git a/winsup/utils/testsuite.cc b/winsup/utils/testsuite.cc
index 23ed8e0d8..ef9f14fa7 100644
--- a/winsup/utils/testsuite.cc
+++ b/winsup/utils/testsuite.cc
@@ -15,22 +15,9 @@ details. */
 #include 
 #define WIN32_LEAN_AND_MEAN
 #include 
-#ifndef TESTSUITE
-#define TESTSUITE
-#endif
+#include "path.h"
 #include "testsuite.h"
 
-typedef struct
-  {
-const char *cwd;/* in win32 form, as if by GetCurrentDirectory */
-const char *posix;  /* input */
-const char *win32;  /* expected output */
-  } test_t;
-
-#define TESTSUITE_TESTS
-#include "testsuite.h"
-#undef TESTSUITE_TESTS
-
 static int curtest;
 
 /* A replacement for the w32api GetCurrentDirectory() that returns
@@ -55,7 +42,21 @@ testsuite_getcwd (DWORD nBufferLength, LPSTR lpBuffer)
   return len;
 }
 
-extern char *cygpath (const char *s, ...);
+/*
+  A replacement for read_mounts that installs the test mount table
+ */
+void
+testsuite_read_mounts (void)
+{
+  int i;
+  for (i = 0; test_mount_table[i].posix; i++)
+{
+  mount_table[i] = test_mount_table[i];
+}
+  max_mount_entry = i;
+}
+
+WCHAR cygwin_dll_path[32768];
 
 int
 main (int argc, char **argv)
diff --git a/winsup/utils/testsuite.h b/winsup/utils/testsuite.h
index 0dd63

Re: cygpath -w space becomes line breaks?

[Andrey Repin via Cygwin]

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?

[斟酌鵬兄 via Cygwin]

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?

[Achim Gratz]

> 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?

[斟酌鵬兄 via Cygwin]

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)

[Ernie Rael]

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

[Ernie Rael]

(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

[Andrey Repin]

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

[Lee]

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

[Brian Inglis]

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

[Alfred von Campe]

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

[Frank Redeker]

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

[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



--
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]

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

[Chris Wagner]

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

[Garber, Dave (BHGE, Non-GE)]

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

[Achim Gratz]

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

[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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

cygpath -u converts quoted UNC paths to local

[Andrey Repin]

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

[Thomas Wolff]

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

[Brian Inglis]

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

[Achim Gratz]

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

[Steven Penny]

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

[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.


--
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

[cyg Simple]

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

[Corinna Vinschen]

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

[Steven Penny]

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)

[Nellis, Kenneth (Conduent)]

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)

[Marco Atzeri]

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)

[Chevallier Yves]

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> 
<edde67b3a1724bb484eb82cd48dce...@de01ex22.global.jhcn.net>

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)

[Marco Atzeri]

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)

[Chevallier Yves]

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 <ychevall...@etel.ch>
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)

[Marco Atzeri]

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)

[Chevallier Yves]

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: 
<caa65n5wf9ri_igb1oscx9deg6rttytvhyukfq012dpqmbdz...@mail.gmail.com> 
<0d835e9b9cd07f40a48423f80d3b5a704bc07...@usa7109mb022.na.xerox.net> 
<vn4ufcp1liuesob71tg3ep64p2lreeu...@4ax.com> 
<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:
   <cygwin-get.123_...@cygwin.com>

To get an index with subject and author for messages 123-456 , mail:
   <cygwin-index.123_...@cygwin.com>

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:
   <cygwin-thread.12...@cygwin.com>"

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)

[Brian Inglis]

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)

[Nellis, Kenneth (Conduent)]

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)

[cyg Simple]

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)

[Brian Inglis]

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)

[Brian Inglis]

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)

[Andrew Schulman]

> 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)

[Nellis, Kenneth (Conduent)]

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)

[Yves Chevallier]

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)

[Marco Atzeri]

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)

[David Macek]

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)

[David Macek]

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)

[cyg Simple]

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)

[Eric Blake]

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)

[cyg Simple]

binD9fTojUuRq.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message

cygpath compatiblity break (v2.1 -> v2.7)

[Chevallier Yves]

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)

[cyg Simple]

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)

[Andrey Repin]

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)

[cyg Simple]

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)

[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.

-- 
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)

[Nellis, Kenneth (Conduent)]

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)

[Andrey Repin]

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)

[cyg Simple]

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)

[Nellis, Kenneth (Conduent)]

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)

[Andrey Repin]

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)

[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?

$ 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

[Corinna Vinschen]

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

[Nellis, Kenneth (Conduent)]

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

[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:
> 
> > 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

[Thomas Wolff]

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

[Nellis, Kenneth (Conduent)]

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

[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?

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

[Thomas Wolff]

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

[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.


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

[cyg Simple]

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

[Brian Inglis]

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

[Sam Edge]

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

[Eliot Moss]

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

[Sam Edge]

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

[Eliot Moss]

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