Workaround:
find . -delete
Bob
not the first thing one one think of to rm a dir tree.
I didn't even know find had a delete op...
(use find alot, but 70% of the time it's to pipe into xargs...)
Jim Meyering wrote:
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
...
POSIX requires rm to reject any attempt to delete an explicitly specified
. or .. argument (or any argument whose last component is one of those):
Hmm... Wow. I decided to check
Bob Proulx writes:
Jim Meyering wrote:
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
...
POSIX requires rm to reject any attempt to delete an explicitly specified
. or .. argument (or any argument whose last component is one of those):
Bob Proulx wrote (Monday, September 03, 2012 9:51 AM)
Jim Meyering wrote:
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
...
POSIX requires rm to reject any attempt to delete an explicitly specified
. or .. argument (or any argument whose last
Alan Curry wrote:
Bob Proulx writes:
Jim Meyering wrote:
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
...
POSIX requires rm to reject any attempt to delete an explicitly specified
. or .. argument (or any argument whose last component is one
Jim Meyering writes:
Alan Curry wrote:
rm -rf $PWD, meaning basically the same thing as rm -rf ., works, and leaves
If you use that, in general you would want to add quotes,
in case there are spaces or other shell meta-characters:
rm -rf $PWD
Well, when I do it I'm in zsh which
Alan Curry wrote:
Jim Meyering writes:
Alan Curry wrote:
rm -rf $PWD, meaning basically the same thing as rm -rf ., works, and
leaves
If you use that, in general you would want to add quotes,
in case there are spaces or other shell meta-characters:
rm -rf $PWD
Well, when I do it
Jim Meyering wrote:
I see from your mention of . below that you are objecting
to rm's refusal to remove . or ...
---
I see from your response that you misunderstood
what I wrote. There was no mention of ... I wouldn't expect
rm to crawl backward out of a rm in any even -- error
Linda Walsh coreut...@tlinx.org writes:
But you fail to follow the earlier stated POSIX
requirement:
You failed to read the second paragraph:
If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if
On Sun, Sep 2, 2012, at 18:10, Jim Meyering wrote:
Sure, but please s/recognized/accepted/.
Then let it be, as for me accepted means just about
the opposite of ignored. I chose recognized because
'touch' reacts to an option it does not know at all with:
unrecognized option.
$ touch --the bell
Andreas Schwab wrote:
[...] read the second paragraph:
If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if
an operand resolves to the root directory, rm shall write a
diagnostic message to
Andreas Schwab wrote:
If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if
an operand resolves to the root directory, rm shall write a
diagnostic message to standard error and do nothing more
Benno Schulenberg wrote:
On Sun, Sep 2, 2012, at 18:10, Jim Meyering wrote:
Sure, but please s/recognized/accepted/.
Then let it be, as for me accepted means just about
the opposite of ignored. I chose recognized because
'touch' reacts to an option it does not know at all with:
I was about to suggest the following, on GNU/Linux:
# Don't do this unless you know what you're doing!
rm -fr /proc/self/cwd/
Except it doesn't work! Not even if I append '.':
$ mkdir /tmp/victim
$ cd /tmp/victim
$ touch foo
$ rm -fr /proc/self/cwd/
rm: cannot remove
On 09/03/2012 10:04 PM, Paul Eggert wrote:
I was about to suggest the following, on GNU/Linux:
# Don't do this unless you know what you're doing!
rm -fr /proc/self/cwd/
Except it doesn't work! Not even if I append '.':
$ mkdir /tmp/victim
$ cd /tmp/victim
$ touch foo
$
On 09/03/2012 10:20 PM, Bernhard Voelker wrote:
the question is what rm should remove:
the symlink or the target?
The convention in POSIX is that if a symlink is
followed by '/', it's dereferenced. So this does
appear to be a bug in coreutils 'rm'.
I confirmed that the bug does not occur with
16 matches
Mail list logo
