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

[Paul Eggert]

On 02/21/2017 05:42 AM, Eric Blake wrote:
> "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."

The same wording is in the first version of POSIX that standardized 
'rm', namely IEEE Std 1003.2-1992 section 4.53.2 lines 8384-6. So we are 
looking at 25 years' worth of standardization here.

Going back even further in time, 7th Edition Unix 'rm' was confused in 
this area. Although 'rm -r ..' had the POSIX-specified behavior, 'rm -r 
.' removed all subfiles and then quietly succeeded without removing '.', 
and there were other complications. Presumably this mess is what the 
early-1990 standardizers were trying to avoid.

At any rate I agree that the requested behavior should be enabled only 
via a new option. Regardless of what one thinks 'rm' should do if we 
could redesign it from scratch, there's too much dead weight of history 
here.