[EMAIL PROTECTED] (Eric Blake) wrote: >> 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
Not if I deem that behavior senseless :-) Can you imagine any real user (non-standards-weenie) *wanting* or even expecting that behavior? The few people I've shown that example to in person have always looked a little slack-jawed and expressed dismay that such silly behavior is mandated. > 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. Right. But as long as Linux's rename had the unwanted behavior, I was unwilling to impose the overhead of a wrapper. Now that constraint is removed. > 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(). I don't want to give myself that kind of work right now. Besides, I don't lose sleep if a GNU tool or two deviate from POSIX on corner cases like this. One way or another, we'll all converge, eventually. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
