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

[Jim Meyering]

Linda Walsh wrote:
> I'm not sure what the rational for putting in special check to
> try to remove the current directory *before*, it's children is,
> but it's not correct behavior.
>
> It used to be it just 'ignored' an attempt to delete the current dir
> and deleted all the files under it.

I see from your mention of "." below that you are objecting
to rm's refusal to remove "." or "..".

Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:

    $ rm -rf .; rm --version | head -1
    rm: cannot remove `.' or `..'
    rm (GNU fileutils) 3.16

> Now there seems to be a special check for "." and disallow it as a
> rm target.  But that was a safe and portable way to delete all contents.
>
> can't use '*', -- it is expanded differently depending on shell and settings!
>
> I always felt a bit safer if I was able to cd into the dir I wanted, then
> rm -fr from the root of that dir by specifying '.'

POSIX requires rm to reject any attempt to delete an explicitly specified
"." or ".." argument (or any argument whose last component is one of those):

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

> Could that be added back in as a safe and portable way to do rm *, where I
> don't have to worry about whether or not it applies the * will pick up
> hidden files.

I suggest you use Bob's suggestion:

    find . -delete

> I would expect it to delete all but the current inode I'm parked on, and
> for it -- either issue an error or silently ignore ... preferring 'DoWIMean'
> versus 'technically'...as being more user friendly.
>
> Sides -- it normally does depth-first traversal --- since you can't delete
> a dir with contents still in it -- so why different for '.'?

Safety, I suspect.  "." and ".." may not mean anything to a novice.