> > 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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
