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.