Could anybody elaborate me, why my system behaves in this way.
When I type
mv some_symbolic_link/ new_name
(Take a look at / character at end of some_symbolic_link/; also new_name do not exist)
I got:
Cannot move some_symbolic_link/ : It is not a directory
But, when I type it without slash, it works. I known, that symbolic link to directory is not a directory, but …
The behavior you describe seems to be what I would expect. Keep in mind that “mv” is just a rename. When you put a “/” at the end of the name, what is it that you expect to rename?
You mean this:
henk@boven:~/test/sl> l
total 12
drwxr-xr-x 3 henk wij 4096 Mar 4 19:31 ./
drwxr-xr-x 8 henk wij 4096 Mar 4 19:30 ../
lrwxrwxrwx 1 henk wij 3 Mar 4 19:31 bla -> dir/
drwxr-xr-x 2 henk wij 4096 Mar 4 19:31 dir/
henk@boven:~/test/sl> mv bla/ aap
mv: cannot move 'bla/' to 'aap': Not a directory
henk@boven:~/test/sl>
Better show instead of that confusing story telling.
And as @nrickert says, rather logical.
It is logical, but symlink is a concept not everybody must known. For me, when symlink points to an directory, mv should behaves like this symlink (in some cases) is a directory. I known, I should think, in which cases and it maybe creates additional path in code, but changing this behavior is worth some amount of work.
This concept is already from the 1970s (if not earlier). You are not likely to get this changed.
And IMHO you are wrong. Whoever uses Unix/Linux from a shell, should know about symlinks. I admit that the learning curve is steep and sometime harsh upon people. But the saying is: “Unix does not do what you think it should do, it does what you tell it to do”.
But of course you are free to design and program a new mv command that strips the / of the end of a file name when that is superfluous in your opinion.
RTFM: https://www.gnu.org/software/coreutils/manual/html_node/mv-invocation.html
Warning: Avoid specifying a source name with a trailing slash, when it might be a symlink to a directory. Otherwise, mv may do something very surprising, since its behavior depends on the underlying rename system call. On a system with a modern Linux-based kernel, it fails with errno=ENOTDIR. However, on other systems (at least FreeBSD 6.1 and Solaris 10) it silently renames not the symlink but rather the directory referenced by the symlink. See Trailing slashes.