Re: Symlink issue?

[Thomas Wolff <towo@towo.net>]

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.
Thomas
>
> Ken
>