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

Previous Next

Full log

View this message in rfc822 format

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 12339 <at> debbugs.gnu.org
Subject: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is	documented to do so.
Date: Fri, 07 Sep 2012 07:54:56 -0700

Bob Proulx wrote:
> 
> Because I originally voted that this felt like a bug I wanted to state
> that after determining that this has already been legacy system
> historical practice for a very long time that I wouldn't change it
> now.  Portability of applications is more important.
----
	Right now, the feature is unused, So hurting compatibility
is not an issue - users can push for the feature on other systems as needed.

	It certainly isnt' a safety issue, since
rm **
on a bouncy keyboard is alot easier to type than rm -fr *,
and the former will remove all files under the current dir
(just none of the directories)

I suppose rm **;rmdir ** would work -- but but require SHELL.

I think adding the case of rm -fr . or (dirname/.) to delete contents
of the dir, but not the dir itself makes more sense and is safer than
the easier to type rm **


> 
> This isn't a feature that could be working in a script for someone.
> It isn't something that was recently removed that would cause a script
> to break.  A script will run now with the same behavior across
> multiple different types of systems.  I think we should leave things
> unchanged.
----
	It's only been recently that I've noticed rm -fr . not working and
I can't figure out why since it hasn't been around for so long.

	
	Consider the parallel, if I want to make sure I copy the contents
of a dir, I need to use cp dir/. dest/

If I use dir/ or dir, they both end up in dest (even with the "/").

That means without using ".", the contents are not addressable, so what is
demanded by 'cp', is refused by 'rm'.

That is not a consistent user interface and is symptomatic of poor design.

Using "." to reference content of a dir is standard in other utils -- that
it doesn't work in 'rm' goes counter to the idea of how rm works -- you have
to remove contents before trying the current dir.  It isn't logical to think
that it would try the current dir before anything else -- as it goes completely
contrary to how rm has to work.

I say it's a design flaw and inconsistent with other programs.

But if I can set an env var and have it work on my system, someone else
can work to get the core utils to work consistently...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.