1

In my home directory /home/regis, after creating a symbolic link LINK to directory DIR/SUBDIR, and doing cd LINK, I have a conflict between bash and its auto-completer regarding what .. leads to.

For bash auto-completer, .. leads to /home/regis, as the user expects since pwd displays /home/regis/LINK, just like the prompt does with PS1 using \w.

For bash itself, .. leads to DIR and ../.. leads to /home/regis, which means it's using the real path /home/regis/DIR/SUBDIR, as displayed by pwd -P.

Which behaviour should be expected here? Am I doing something wrong here?

/home/regis$ touch FILE
/home/regis$ mkdir -p DIR/SUBDIR
/home/regis$ ln -s DIR/SUBDIR LINK
/home/regis$ cd LINK

/home/regis/LINK$ ls ../FI # autocomplete with TAB succeeds here
/home/regis/LINK$ ls ../FILE # but autocompleted command will fail here
ls: cannot access '../FILE': No such file or directory
/home/regis/LINK$ ls ../../FILE # command succeeds
FILE


$ bash -version
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
ilkkachu
  • 138,973
Regis
  • 13

1 Answers1

0

For bash itself, .. leads to DIR and ../.. leads to /home/regis,

Usually not...

/home/regis/LINK$ ls ../FILE # but autocompleted command will fail here
ls: cannot access '../FILE': No such file or directory
/home/regis/LINK$ ls ../../FILE # command succeeds

...but this isn't Bash, this is ls.

The thing is that Bash tries to be user-friendly, and when you cd through a symlink, it remembers internally the path you took to get there. And then doing e.g. cd .. inside Bash uses that path, so cd LINK; cd .. gets you back to where you started.

But ls is an external process, and it can't know any of that, and just sees itself running in some working directory, which would be /home/regis/DIR/SUBDIR here, regardless of what cd command was used to get there. Well, actually ls just passes the pathname to the operating system, which also doesn't care, but just uses the working directory as it is, and the .. entry as it is in the filesystem.

If you used cd -P LINK instead, the shell would disable that special behaviour and you'd see the path as /home/regis/DIR/SUBDIR in the shell, too. Usually one doesn't bother, because most of the time it works pretty ok, as long as you don't try to go "up" past the point the symlink pointed at.

See also my earlier answer at https://unix.stackexchange.com/a/739426/170373 for a "pretty" ASCII graph on the same subject.

ilkkachu
  • 138,973
  • Thanks. After reading your answer, I tried to remove ls from the equation by doing chmod +x FILE and tried to autocomplete it after cd LINK with ../FI [TAB] and tried to execute it with ../FILE to see what happens.

    Both autocomplete and execution failed, so at least autocomplete is not misleading in this case. But I guess it's because something like stat and sh -c are involved, with the same issue as ls.

     – Regis Apr 26 '23 at 16:09
  • @Regis, right, the shell could resolve that ../FILE back "through" the symlink when executing if it wanted to. Looks like it doesn't, I don't know if there's some particular issue that it could cause – ilkkachu Apr 26 '23 at 17:07