|
From: | Paul Eggert |
Subject: | bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior |
Date: | Tue, 21 Feb 2017 08:55:47 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |