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