Moderators: THIS IS NOT A DUPLICATE!!!! Please remove the duplicate mark.
The answers linked to do not, actually, answer my question, the way the accepted answer does. Google only points at the other answers, which are not actually answer to this particular question.
When following a symbolic link to a directory, the
bash shell kind-of tries to make the illusion that the symbolic link is a real directory.
However, there are many cases where this breaks down. For example, consider that I might have:
then, I have a symlink in my home directory:
ln -s /usr/local/src/project-a-1.0 ~/project
Now, I want to short-cut to work with
So far, so good -- but bash pretend that I'm actually in
~/project, not in the actual working directory. It even pretend when using the
pwd built-in, but of course not when using the
Now, if I want to check out a file in
project-b, I might want to try
vim ../project-b<TAB> to try to make command completion work. However,
bash refuses to complete this, because it thinks that
.. is the directory containing user homes.
However, if I type in
vim ../project-b-2.2/somefile.txt then that works fine, which is what I expected.
Symlinks are not directories, and all kinds of inconveniences and even errors happen because of this mis-feature in bash. I've tried to search for an option to turn this off, but all the google and superuser hits are just about "how to I manually resolve a link path" -- that's not what I want here; I want bash to stop trying to emulate a file system on top of my file system, poorly. Surely, there exists some option that will put correctness in front of illusion?
The "similar questions" popup pointed at two other questions that Google already sent me to; both of them require me to pass the "-P" option to
cd or even recommend using
readlink to figure out the symbolic link target. That's not at all what I'm interested in. I want the built-in
pwd and the shell prompt
$PWD to match the physical output of the
getcwd() system call; those questions don't talk about that at all.