Re: bug in mv (fileutils) 4.1

Thank you for the report!
The way mv works depends on the behavior of `rename' (per POSIX),
and it looks like rename's behavior has changed in Linux within
the last few kernel releases.

When I wrote the section you quote below, mv did indeed
work as described when using the latest version of Linux
available at that time.  With linux-2.4.18, I see the same
behavior you describe.

Note that cp still works as described.
I'll update the documentation wrt mv to say that the behavior
is system-dependent.


Hans Ginzel <[email protected]> wrote:
>    There is in the fileutils.info:
>
> Trailing slashes
> ================
>
>    Some GNU programs (at least `cp' and `mv') allow you to remove any
> trailing slashes from each SOURCE argument before operating on it.  The
> `--strip-trailing-slashes' option enables this behavior.
>
>    This is useful when a SOURCE argument may have a trailing slash and
> specify a symbolic link to a directory.  This scenario is in fact rather
> common because some shells can automatically append a trailing slash
> when performing file name completion on such symbolic links.  Without
> this option, `mv', for example, (via the system's rename function) must
> interpret a trailing slash as a request to dereference the symbolic link
> and so must rename the indirectly referenced _directory_ and not the
> symbolic link.  Although it may seem surprising that such behavior be
> the default, it is required by POSIX.2 and is consistent with other
> parts of that standard.
>
>    I have tried this:
>
> 	export POSIXLY_CORRECT=1
> 	mkdir mv_test
> 	cd mv_test
> 	mkdir a c
> 	ln -s a b
> 	mv -v b/ c
> 	alias mv
> 	which mv
>
> I expected, as is written, that the directory a will be moved into
> directory c (the symbolic link b to directory a will be dereferenced),
> but the link b has been moved. There is no alias for mv, mv resides in
> /bin.