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