Re: mv trailing slash warning

[Paul Eggert]

address@hidden (Eric Blake) writes:

> Why don't rm and rmdir have a --strip-trailing-slashes option?

I'd guess because that option is an ugly hack and we'd rather that the
problem went away....

> we should bring this up with the austin group.

Perhaps, but let's figure out what we want first.

> I agree with your logic here on rename(2) needing to fail on a trailing
> slash if it is also supposed to fail on a trailing dot.  But that doesn't
> necessarily mean that mv(1) need to fail on a trailing slash or dot.

But POSIX says "mv a/ b" does the equivalent of rename("a/", "b").
So if you agree with the logic, then "mv a/ b" must fail.

> Oops - cygwin has a bug in this regards:
> $ mkdir dir
> $ rmdir dir/.
> $ echo $?
> 0
> $ ls dir
> ls: dir: No such file or directory
>
> Is it worth patching coreutils rm and rmdir to work around buggy
> systems that don't follow this POSIX restriction on rmdir()?

Naah, let's just get cygwin fixed.

> On the other hand, since 'mv symlink/ foo' invokes underspecified
> behavior in rename(2), maybe we can get away with deciding that
> mv(1) always behaves as --strip-trailing-slashes

POSIX may be underspecified, but it's not _that_ underspecified.  :-)

I think one could argue that "mv symlink/ foo" should rename the
target of the symlink (which is what Solaris does), or that it should
fail (which is what I'd mildly prefer); but I don't see a way to read
POSIX to say that it allows mv to ignore the slash.

Note that, by this argument, "mv dir/ foo" should fail even if "dir/"
is an ordinary directory and is not a symlink.  So it'd be kind of a
big change.