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 #20 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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.
rm -rf $PWD, meaning basically the same thing as rm -rf ., works, and leaves
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.)
--
Alan Curry
This bug report was last modified 6 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.