error in "cygpath" behavior

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: error in "cygpath" behavior

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[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

[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

[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