bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is

[Jim Meyering]

Alan Curry wrote:
> Bob Proulx writes:
>> Jim Meyering wrote:
>> > Could you be thinking of some other rm?
>> > Coreutils' rm has rejected that for a long time:
>> > ...
>> > POSIX requires rm to reject any attempt to delete an explicitly specified
>> > "." or ".." argument (or any argument whose last component is one of 
>> > those):
>>
>> Hmm...  Wow.  I decided to check HP-UX 11.11, a now rather old release
>> from twelve years ago in 2000, the oldest easily available to me, and
>> got this:
>>
>>   $ /usr/bin/rm -rf .
>>   rm: cannot remove .. or .
>>
>> So I guess GNU coreutils is in good company with traditional Unix
>> systems!  It has definitely been that way for a long time.
>
> Linux has the ability to actually remove a directory that is empty but still
> referenced as the cwd of some process. This ability is non-traditional
> (my fuzzy memory says it showed up some time in the 2.2 or 2.4 era). It's
> worth considering whether this change should be reflected by a relaxation of
> rm's traditional behavior.

I see very little benefit in relaxing this restriction.
Why introduce an incompatibility (slightly dangerous, even) with POSIX
and with such long-standing behavior?

> rm -rf $PWD, meaning basically the same thing as rm -rf ., works, and leaves

If you use that, in general you would want to add quotes,
in case there are spaces or other shell meta-characters:

    rm -rf "$PWD"

> you in a directory so empty that ls -a reports no "." or ".." entries, and no
> file can be created in the current directory. (open and stat and chdir still
> work on . and .. though. They're magic.)