Martin Grosup wrote:
> Hello. Sorry for my bad english. I will try my best:
Thank you for that very detailed report. Details such as you provided
are most appreciated.
However, what you are seeing is not a bug. You are seeing behavior by
the shell trying to help you but instead is only confusing you.
> gw:/home/mag81/incoming # mv --version
> mv (fileutils) 4.1.11
This is unrelated, but when convenient you should update to the later
coreutils-5.x series. It is a whole major number later with various
fixes and improvements.
> gw:/home/mag81 # l in* v*
> lrwxrwxrwx 1 root root 47 Jul 18 20:29 incoming ->
> /home/mldonkey/mldonkey-distrib-2.5-3/incoming/
> lrwxrwxrwx 1 root root 13 Mar 4 2003 video1 -> /data1/video/
> lrwxrwxrwx 1 root root 12 Oct 18 11:01 video2 -> /data2/video/
Symlinks are purely name translations. But the shell tries to hide
this from you.
> gw:/home/mag81/incoming # touch testfile
> gw:/home/mag81/incoming # mv testfile ../video2/
> mv: cannot stat `../video2/testfile': Not a directory
Correct. /home/mag81/incoming is really
/home/mldonkey/mldonkey-distrib-2.5-3/incoming/ and therefore
../video2/testfile is really
/home/mldonkey/mldonkey-distrib-2.5-3/video2/testfile. Does that
directory exist? The command says no.
> gw:/home/mag81/incoming # mv testfile ../video2
../video2 does not have a trailing slash and so can be a filename.
Again, symbolic links are purely name translations. Remember you are
NOT in /home/mag81/incoming. You are in
/home/mldonkey/mldonkey-distrib-2.5-3/incoming and .. in that
directory is /home/mldonkey/mldonkey-distrib-2.5-3. So this command
is really the following.
mv /home/mldonkey/mldonkey-distrib-2.5-3/incoming/testfile
/home/mldonkey/mldonkey-distrib-2.5-3/video2
You will find your file now named video2. The commands that you run
at the shell are not fooled by the shell. To them the files '.' and
'..' are real files in your directory. Try these commands and see
that the inodes are different for your 'incoming' directory. If you
were in /home/mag81/incoming then .. would be the same as /home/mag81,
right? But they are not if a symlink too you someplace else.
cd /home/mag81/incoming
ls -ldi .. /home/mag81
Starting with AT&T ksh and later lookalikes such as bash the shell
tries to hide symlinks from you. So if cd into a symlink it won't
show you the actual directory. It will instead store the way you got
there into the PWD variable. That enables you to 'cd ..' and get out
the same way you got in. A 'cd ..' to the shell just pulls the last
entry off of $PWD and then changes directory to the resulting path.
Many people like this behavior and so it is the default. I personally
do not. But symbolic links one way will confuse 50% of the people
and the other way will confuse the other 50%. There is no way to
please everyone.
The bash shell includes a way to turn this default behavior off. Try
the following. (Use 'set +P' to turn it back to the default mode.)
set -P
The manual for bash states the following.
-P If set, the shell does not follow symbolic
links when executing commands such as cd
that change the current working directory.
It uses the physical directory structure
instead. By default, bash follows the log
ical chain of directories when performing
commands which change the current direc
tory.
Try running your commands in this mode to understand what is
happening.
Hope this helps,
Bob
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
