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

Message #89 received at 12339 <at> debbugs.gnu.org (full text, mbox):

From: "Linda A. Walsh" <law <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Jim Meyering <meyering <at> redhat.com>,
	"12339 <at> debbugs.gnu.org" <12339 <at> debbugs.gnu.org>
Subject: Re: bug#12339: [PATCH] rm: avoid bogus diagnostic for a
	slash-decorated symlink-to-dir
Date: Tue, 04 Sep 2012 16:21:53 -0700

[Message part 1 (text/plain, inline)]

Paul Eggert wrote:
> On 09/04/2012 10:46 AM, Linda A. Walsh wrote:
>   
>> I would assert that the trailing "." shouldn't be stripped either.
>>     
>
> If we were designing anew, I'd be inclined to agree with you.
> But there are probably people expecting the standard behavior now,
>   
----
i.e. expecting it to do nothing useful other than issue an error?

Who would type that in, expecting that?

What useful purpose does it serve?


> and there's an argument for not departing from the standard
> unless there's a good reason.
>   
Usability, Expressiveness.

> Here, if we can provide a command "rm -fr foo/" to do what you
> want, then I hope it's merely a minor glitch that "rm -fr foo/."
>   
Ok, will foo/ remove the contents only and not the directory?

If so, then it's a replacement -- that sounds like what is being
talked about .. yes?

It seems so fragile -- because some utils require the /. to make sure 
you don't
ALSO remove the directory.

if I remove foo/.

I know, unambigously, that the directory "foo won't be removed.

With "foo/", it will depend on the program.

That means other programs will have to change to be compat with the
new standard -- when they were all compat before when
foo/. did a recursive remove and gave an error at the end about
can't remove "."....

That was a behavior I've relied on...(i.e. if it really did remove
".", that would defeat the purpose of the of the safety invocation.

However, adding foo/ -- does that imply that ./ will also work?

so now rm -fr ./ will work?   That's awfully close to "rm -fr /."
just as rm -fr ./* is close to rm -fr /.*

I've never relied on rm to protect me from rm -fr /, which
is why I have tended to use relative paths with "." and ending
in "." if I wanted to keep the dir, or not -- as there is
ALOT of code out there that removes trailing "slashes"...

(like the code under discussion -- perfect example)....it is by far not
the only one to treat '/' as option at the end of a path.

[Message part 2 (text/html, inline)]

Previous Next

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