Re: mv trailing slash warning

[Jim Meyering]

address@hidden (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.