[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated syml
From: |
Linda A. Walsh |
Subject: |
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir |
Date: |
Tue, 04 Sep 2012 16:21:53 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 |
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.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Linda A. Walsh, 2012/09/04
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Eric Blake, 2012/09/04
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Paul Eggert, 2012/09/04
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir,
Linda A. Walsh <=
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Paul Eggert, 2012/09/04
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Linda A. Walsh, 2012/09/04
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Paul Eggert, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Bernhard Voelker, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Linda A. Walsh, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Paul Eggert, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Linda A. Walsh, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Paul Eggert, 2012/09/05
- bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir, Linda Walsh, 2012/09/05
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so., Bernhard Voelker, 2012/09/06