Subject: bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

From: Eric Blake <[email-masked]>
Date: Tue, 21 Feb 2017 07:42:41 -0600

On 02/21/2017 02:41 AM, L A Walsh wrote:
> 
>     Do you really need me to find the older version
> of 'rm' in your source tree?

It wouldn't hurt to point out which commit id changed behavior, if you
indeed want to call that commit a regression.  Being able to read the
commit itself, as well as mailing list traffic at the time, will help
current readers get a more-informed picture of whether such a change was
intentional or accidental.

> 
>     you know as well as I do, that the verbiage
> about disallowing all subpaths under '.' wasn't in earlier
> posix versions (say 2001 or before).

So I spent 20 more minutes on this, and researched a bit further: here's
what POSIX 2001 says:

http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html

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

I then went back to SUSv2, published in 1997:

http://pubs.opengroup.org/onlinepubs/007908799/xcu/rm.html

"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 will
write a diagnostic message to standard error and do nothing more with
such operands."

You ARE correct that it was POSIX 2008 that introduced the wording "or
if an operand resolves to the root directory" to cover an early exit on
an attempt to remove '/', but the discussion here is about an early exit
on an attempt to remove '.', which, contrary to your claim, appears to
always have been in POSIX as far as I can tell (and even if it has not
always been in POSIX, the fact that I can quote a 20-year-old document
that describes current behavior means that any change to a default now
would be breaking 20 years of what script writers have come to rely on).

I'm all ears if you can point to an even-older standards document worded
differently, but at this point, I don't think you're going to find one.

And I still maintain that a patch that adds a new option to avoid the
early exit on '.' may be acceptable, but that it would have to be a new
option and not the default behavior.  But I'm not bothered enough by the
current situation to be the one to write such a patch.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org