AT-HE wrote:
> if you have a simlink pointing to a directory, chdir to that
> symlink dir, and type something with '..', you access the
> parent of real directory, not previous simlinked one.
Symlinks violate some principles of least surprise. Therefore it is
not surprise that it is impossible to make all uses of symlinks
unsurprising.
> it is not supposed to be like, may be dangerous in a shared
> environment.
What you are describing is actually the way it is supposed to work.
Symbolic links were developed in BSD and a wonderful invention they
have proved to be. But they are not entirely consistent throughout.
They do not change the behavior of the filesystem. They are simply a
symbolic name translation for that individual target.
Instead of the default bash behavior of tracking the logical path try
it with this option set:
set -o physical
In GNU bash the 'set -o physical' option turns off this logical path
tracking of the shell. Setting that option with your example would
report the new name of the physical present working directory.
That will make what is actually happening much more obvious.
What you are seeing with logical path tracking is considered a feature
by many. As an old timer I don't like it since it causes confusion.
But 99% of everyone I talk with about this prefers the new behavior
which creates a facade around symlinks. (New is relative when the
behavior has been around as many years as this one.) I originally saw
this introduced in ksh, the Korn shell, and bash has followed ksh in
this matter.
> i tested only (but not limited) with cd, cat, vi, chmod and
> chown; all returning described results.
Of the things you tested all but cd are external command unrelated to
bash itself. That is almost always a good clue that this isn't
something related to the shell.
Note that '.' and '..' are real directory entries. They are not
pseudo entries as some appear to believe. The shell covers them with
fake entires to change the behavior into logical paths when symlinks
are in use. But that does not remove the underyling entries. All
operating system kernel system calls use the real entries. The fake
entries are an imaginary world created within the process model of
new-style, symlink-aware command shells.
info bash
`cd'
cd [-LP] [DIRECTORY]
Change the current working directory to DIRECTORY. If DIRECTORY
is not given, the value of the `HOME' shell variable is used. If
the shell variable `CDPATH' exists, it is used as a search path.
If DIRECTORY begins with a slash, `CDPATH' is not used. The `-P'
option means to not follow symbolic links; symbolic links are
followed by default or with the `-L' option. If DIRECTORY is `-',
it is equivalent to `$OLDPWD'. The return status is zero if the
directory is successfully changed, non-zero otherwise.
`pwd'
pwd [-LP]
Print the current working directory. If the `-P' option is
supplied, the path printed will not contain symbolic links. If
the `-L' option is supplied, the path printed may contain symbolic
links. The return status is zero unless an error is encountered
while determining the name of the current directory or an invalid
option is supplied.
* The Bash `cd' and `pwd' builtins (*note Bourne Shell Builtins::.)
each take `-L' and `-P' builtins to switch between logical and
physical modes.
`set'
set [--abefhkmnptuvxBCHP] [-o OPTION] [ARGUMENT ...]
`-o OPTION-NAME'
`physical'
Same as `-P'.
`-P'
If set, do not follow symbolic links when performing commands
such as `cd' which change the current directory. The
physical directory is used instead. By default, Bash follows
the logical chain of directories when performing commands
which change the current directory.
For example, if `/usr/sys' is a symbolic link to
`/usr/local/sys' then:
$ cd /usr/sys; echo $PWD
/usr/sys
$ cd ..; pwd
/usr
If `set -P' is on, then:
$ cd /usr/sys; echo $PWD
/usr/local/sys
$ cd ..; pwd
/usr/local
Try setting either 'set -o physical' or equivalently 'set -P' in your
$HOME/.bashrc file and you will always follow the physical path.
Hope this helps,
Bob
