GNU bug report logs -
#12339
Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Previous Next
Reported by: Linda Walsh <coreutils <at> tlinx.org>
Date: Mon, 3 Sep 2012 00:34:02 UTC
Severity: normal
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 6 years and 186 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.