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. _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
