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

[Jim Meyering]

Paul Eggert <eggert@twinsun.com> wrote:

>> From: Jim Meyering <jim@meyering.net>
>> 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

Right.  That was my point.  But I didn't realize it was limited
to the case in which dir is a symlink to a directory.

> 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.

Thanks.  If you think it's worthwhile, go ahead,
but don't feel you need to do it on my account.
In spite of how it might sound some of the time, I'm no slave of POSIX :-)