Re: mv trailing slash warning

[Eric Blake]

> 
> As you can imagine, I find the POSIX-required behavior to be senseless.
> The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine.
> Now that Linux/glibc provides a sane rename function, I'm tempted
> to make mv work in the above manner on all systems rather than allowing
> the crazy move-pointed-to-directory behavior on systems with a
> technically-conforming rename.
> 
> The wrapper will incur the expense of a syscall or two on losing systems
> when the first argument ends with `/'.

If you do that, you need to make sure POSIXLY_CORRECT still
gets the POSIX behavior of move-pointed-to-directory.  But
wasn't this the reason that --strip-trailing-slashes was created
as an option?  That way, a user can do
alias mv='mv --strip-trailing-slashes'
and get the sane behavior of always moving the symlink, not the
pointed-to-directory, regardless of whether rename() is
conformant or not, and regardless of whether their shell's
tab-completion puts slashes on symlinks-to-directories.

Meanwhile, since you think that the POSIX definition of rename()
is insane, try filing an aardvark to allow an implementation-defined
choice between moving the symlink/moving the directory, rather
than the current mandated semantics of moving the directory.  That
way, Linux 2.6.x would still be able to comply to POSIX with what
you term to be saner semantics (personally, I like the POSIX-mandated
semantics, as it provides a consistent way to choose between
operating on the symlink vs. operating on what it points to by
the presence of the trailing slash, and it is not just rename() that
is affected by POSIX semantics).  Or you could file an aardvark
on mv(1) to allow an implementation to always strip trailing slashes
before calling rename().

--
Eric Blake