Re: fileutils: inconsistent behaviour stripping / from end of filenames

[Paul Eggert]

> From: Jim Meyering <address@hidden>
> Date: Thu, 13 Sep 2001 19:36:07 +0200
> 
> Doesn't POSIX require `rm -r dir/'
> to be treated just like `rm -r dir/.' ?

I'm afraid not -- at least, not by my reading.
The rm spec says (d7 lines 31692-31695):

   If either of the files dot or dot-dot are specified as the basename
   portion of an operand (that is, the final pathname component), rm
   shall write a diagnostic message to standard error and do nothing
   more with such operands.

Hence 'rm -r dir/.' must fail.  But the basename portion of 'dir/'
(i.e., the final pathname component) is 'dir', so this clause does not
apply.  The rest of the 'rm' spec makes no special case for '.' or for
trailing '/', so 'rm -r dir/' must operate recursively and then invoke
rmdir("dir/").

The rmdir command is similar, as the command "rmdir dir/" is supposed
to invoke rmdir("dir/").

And the rmdir function says that if "dir" is an empty directory, or is
a symbolic link to an empty directory, then rmdir("dir/") should
attempt to remove that directory.

One could argue that this is a bug in POSIX.  Pathname resolution
requires that "dir/" be treated as "dir/." if dir is a symlink to a
directory, so it seems a bit odd that "rm" and the two "rmdir"s
disagree with this convention.  If you like, I can file a formal
interpretation request.