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.