Symlink issue?

[Brian Inglis]

On 2021-08-21 18:40, Thomas Wolff wrote:
> 
> 
> Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin:
>> On 8/21/2021 4:15 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin 
>> wrote:
>>> Hi,
>>>
>>> Please consider the following Cygwin session:
>>>
>>> $ cd ~
>>> $ pwd
>>> /home/user
>>> $ touch file
>>> $ ls file
>>> file
>>> $ cygpath -w ~
>>> C:\cygwin64\home\user
>>> $ mkdir /cygdrive/g/cygwin/dir
>>> $ ln -s /cygdrive/g/cygwin/dir ./dir
>>> $ ls -l dir
>>> ... dir -> /cygdrive/g/cygwin/dir/
>>> $ cd dir
>>> $ pwd
>>> /home/user/dir
>>> $ cygpath -w `pwd`
>>> G:\cygwin\dir
>>> $ ls -l ../fil<TAB>  (this expands to ../file but when Enter is hit):
>>> ls: cannot access '../file': No such file or directory
>>>
>>> so basically "file" is not accessible with the relative dot-dot link,
>>> even though somehow readline (bash completion) can figure it out and 
>>> suggest
>>> the correct completion.
>>>
>>> Is this a Cygwin bug?
>>
>> I don't think so.  I see identical behavior on Linux (using /tmp/dir 
>> instead of /cygdrive/g/cygwin/dir).
>>
>> Pathname resolution proceeds from left to right, with symlinks 
>> expanded as they are encountered.  See "Pathname resolution" in
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
>>
>> When the CWD is /home/user/dir, the resolution of ../file goes like this:
>>
>> ../file = /home/user/dir/../file
>>         = /cygdrive/g/cygwin/dir/../file
>>         = /cygdrive/g/cygwin/file,
>>
>> which doesn't exist.
>>
>> I don't know why bash completion suggests something different.  My 
>> guess (and it's only a guess) is that bash completion takes a shortcut 
>> for performance reasons.
> The symlink/.. confusion is a dreadful trap since Unix times.
> Unfortunately, bash completion does not consider path resolution, so if 
> any, it's a bash completion bug.

Try using cd -P (via alias?) which may resolve physically if it works.
Otherwise enjoy the quirks of cd via symlinks and .. resolution after.

-- 
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.
[Data in binary units and prefixes, physical quantities in SI.]