Linda Walsh wrote:
I proposed adding a ENV var that would need to be specified to get
the new behavior. Thus it *would not* be changing default behavior.
Does everyone get that... as that's been offered as a an acceptable
compromise.
We will not be adding new behavior that is enabled by an
Jim Meyering wrote:
Linda Walsh wrote:
...
GNU needs to be clear their priorities -- maintaining software
freedom, or bowing down to corporate powers... POSIX isn't
While POSIX is in general a very good baseline, no one here conforms
blindly. If POSIX is wrong, we'll lobby to change it,
On 09/07/2012 08:16 AM, Linda Walsh wrote:
We try to make the tools as useful as possible, sometimes adding features
when we deem them worthwhile. However, we are very much against changing
the *default* behavior (behavior that has been that way for over 20
years and that is compatible with
Eric Blake wrote:
I personally detest new env-vars that change long-standing behavior,
because you then have to audit EVERY SINGLE SCRIPT to ensure that its
use is unimpacted if the new env-var is set. It must either be an
existing env-var, or my personal preference of a new --long-option.
Bob Proulx wrote:
Because I originally voted that this felt like a bug I wanted to state
that after determining that this has already been legacy system
historical practice for a very long time that I wouldn't change it
now. Portability of applications is more important.
Right
Eric Blake wrote:
Then set up a shell alias or a wrapper script that comes first in your
$PATH. Then it is under your explicit control, while the default is
still appropriate for everyone else.
Just because the defaults don't match your expectations doesn't mean you
can't change the
On 09/07/2012 08:54 AM, Linda Walsh wrote:
Using . to reference content of a dir is standard in other utils -- that
it doesn't work in 'rm' goes counter to the idea of how rm works -- you
have
to remove contents before trying the current dir. It isn't logical to
think
that it would try
Eric Blake wrote:
On 09/07/2012 08:54 AM, Linda Walsh wrote:
Using . to reference content of a dir is standard in other utils -- that
it doesn't work in 'rm' goes counter to the idea of how rm works -- you
have
to remove contents before trying the current dir. It isn't logical to
think
that
On 09/07/2012 02:56 PM, Linda Walsh wrote:
Really, I didn't say rm -fr . should *delete* the current directory --
IT SHOULD
FAIL -- you are 100% correct.
But it is true that anyone who knows the smallest bit about unix knows
that you have to empty the directory before deleting the
Eric Blake wrote:
You therefore may have a valid point that POSIX standardized something
that did not match existing practice at the time, and therefore, it
would be reasonable to propose a POSIX defect that requires early
failure on .., but changes the behavior on . and / to only permit,
but
Eric Blake writes:
Indeed, reading the original V7 source code from 1979:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=3DV7/usr/src/cmd/rm.c
[...]
shows that _only_ .. was special, . was attempted in-place and
didn't fail until the unlink(.) after the directory itself had been
emptied.
On 09/07/2012 03:30 PM, Linda Walsh wrote:
Not that I believe that, -- I just think most users aren't
aware or don't care, but that would be the reasoning. I get it here,
why would I expect someone who's job is to come up with lame rules that
defy standard practice (last I looked they
On 09/07/2012 03:20 PM, Eric Blake wrote:
Indeed, reading the original V7 source code from 1979:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/rm.c
shows that _only_ .. was special, . was attempted in-place and
didn't fail until the unlink(.) after the directory itself had
Eric Blake wrote:
The rm utility is forbidden to remove the names dot and dot-dot in order to
avoid the consequences of inadvertently doing something like:
rm −r .*
---
Which is why, IMO, I thought rm -r .* should ask if they really want to remove
all files under . as the first question, as
On 09/07/2012 09:02 AM, Linda Walsh wrote:
--- src/remove.c2011-10-10 00:56:46.0 -0700
+++ src/remove.c.new2012-09-06 14:28:07.816810683 -0700
Thanks for making an attempt to show what you want in code. However,
you provided no ChangeLog entry, no mention in NEWS and no
Alan Curry wrote:
Eric Blake writes:
if (isdot(cp)) {
fprintf(stderr, rm: cannot remove `.' or `..'\n);
return (0);
---
The thing is, by doing rm -rf on ., I am not trying to remove . or ..
I'm trying to remove the files in it.
Other wise there is
Eric Blake wrote:
...codeing stuff...
Thanks for the advice... will take it appreciatively, however
it was a few hours effort in unfamiliar code.
I certainly wouldn't write NEWS/CHANGES if I didn't have an initial
agreement that it would go in.
More to the point. Others are objecting,
On 09/07/2012 06:02 PM, Linda Walsh wrote:
The thing is, by doing rm -rf on ., I am not trying to remove . or ..
I'm trying to remove the files in it.
Other wise there is no way to specify, using rm to delete the contents
of a directory but not the directory itself.
Yes there is, and Paul
Eric Blake wrote:
On 09/07/2012 06:02 PM, Linda Walsh wrote:
The thing is, by doing rm -rf on ., I am not trying to remove . or ..
I'm trying to remove the files in it.
Other wise there is no way to specify, using rm to delete the contents
of a directory but not the directory itself.
Yes
On 09/07/2012 06:25 PM, Linda Walsh wrote:
I don't want to get the shell involved
That's not a reasonable constraint. The shell is
a standard tool for solving this sort of problem,
and involving the shell solves this problem.
The shell is one of the things I'm trying not to have a dependency on. It
doesn't pass a reliability test as it does too much.
I want a utility that removes files -- single files or depth recursive
and it can fail on the current dir or target dir -- after
finishes like it is documented to do ..
Linda Walsh writes:
So far no one has addressed when the change in -f' went in
NOT to ignore the non-deletable dir . and continue recursive delete,
In the historic sources I pointed out earlier (4.3BSD and 4.3BSD-Reno) the -f
option is not consulted before rejecting removal of . so I don't
Alan Curry wrote:
Linda Walsh writes:
So far no one has addressed when the change in -f' went in
NOT to ignore the non-deletable dir . and continue recursive delete,
In the historic sources I pointed out earlier (4.3BSD and 4.3BSD-Reno) the -f
option is not consulted before rejecting
On 09/07/2012 08:06 PM, Linda Walsh wrote:
The shell is one of the things I'm trying not
to have a dependency on.
That sounds unnecessarily impractical. It's been
decades since I used a system that had 'rm' but
didn't have a shell that could solve this problem easily.
By the way, Alan, that
Linda Walsh writes:
Alan Curry wrote:
Linda Walsh writes:
So far no one has addressed when the change in -f' went in
NOT to ignore the non-deletable dir . and continue recursive delete,
In the historic sources I pointed out earlier (4.3BSD and 4.3BSD-Reno) the
-f
option is not
Linda Walsh wrote:
This doesn't check POSIX_CORRECTLY, but it does fix the reported problem
rm -fr in . removes all files and leaves the dir:
Ishtar:/tmp/ttt touch one two three
Ishtar:/tmp/ttt cd ..
Ishtar:/tmp rm -fr ttt/.
Ishtar:/tmp ll ttt
total 0
---
Also works cd'd into the dir
Jim Meyering wrote:
Thanks for the patch, but it would be pretty rotten for GNU rm to make
it so rm -rf . deletes everything under ., while all other vendor
rm programs diagnose the POSIX-mandated error. People would curse us
for making GNU rm remove their precious files when they
On September 6, 2012 at 12:56 PM Linda Walsh coreut...@tlinx.org wrote:
Jim Meyering wrote:
Thanks for the patch, but it would be pretty rotten for GNU rm to make
it so rm -rf . deletes everything under ., while all other vendor
rm programs diagnose the POSIX-mandated error. People
Linda Walsh wrote:
...
GNU needs to be clear their priorities -- maintaining software
freedom, or bowing down to corporate powers... POSIX isn't
While POSIX is in general a very good baseline, no one here conforms
blindly. If POSIX is wrong, we'll lobby to change it, or, when
that fails,
Jim Meyering wrote:
Linda Walsh wrote:
...
GNU needs to be clear their priorities -- maintaining software
freedom, or bowing down to corporate powers... POSIX isn't
While POSIX is in general a very good baseline, no one here conforms
blindly. If POSIX is wrong, we'll lobby to change
Bernhard Voelker wrote:
On September 6, 2012 at 12:56 PM Linda Walsh coreut...@tlinx.org wrote:
Jim Meyering wrote:
Thanks for the patch, but it would be pretty rotten for GNU rm to make
it so rm -rf . deletes everything under ., while all other vendor
rm programs diagnose the
Jim Meyering wrote:
...
I'll post this new pair of rm-related patches in a minute.
Here's what I'm ready to push.
Finally, I'm not adding a test for what happens
when one tries to run rm -r s/ (with s being a symlink),
since that is so system-specific. I suppose I could add
test solely to
On 09/05/2012 07:56 AM, Jim Meyering wrote:
+ /* When failing to rmdir an unreadable directory, the typical errno value
+ is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
+ When that happens and the errno value from the failed open is EPERM
+ or EACCES, use the
Paul Eggert wrote:
On 09/05/2012 07:56 AM, Jim Meyering wrote:
+ /* When failing to rmdir an unreadable directory, the typical errno value
+ is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
+ When that happens and the errno value from the failed open is EPERM
+
Jim Meyering wrote:
Paul Eggert wrote:
On 09/05/2012 07:56 AM, Jim Meyering wrote:
+ /* When failing to rmdir an unreadable directory, the typical errno value
+ is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
+ When that happens and the errno value from the
Thanks for the efforts at cleaning things up...it's appreciated
even if it's not exactly what I might want...just wanted to
emphasize that your I appreciate the work you are doing!..
I just don't always appreciate the 'posixifing' of linux's default
behavior...but then I like powerful interface
This doesn't check POSIX_CORRECTLY, but it does fix the reported problem
rm -fr in . removes all files and leaves the dir:
Ishtar:/tmp/ttt touch one two three
Ishtar:/tmp/ttt cd ..
Ishtar:/tmp rm -fr ttt/.
Ishtar:/tmp ll ttt
total 0
---
Also works cd'd into the dir and doing an rm -fr .
I'll
Paul Eggert wrote:
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
On 09/04/2012 12:42 PM, Jim Meyering wrote:
I have mixed feelings, but am leaning towards the
Solaris 11/FreeBSD behavior.
They must have fixed it for Solaris, here's an older one:
$ uname -sr ; mkdir d; ln -s d s; /bin/rm -r s/; ls
SunOS 5.9
d
Have a nice day,
Berny
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
$ rm -fr /proc/self/cwd/
On 09/04/2012 02:55 PM, Jim Meyering wrote:
With the following patch, I see new behavior.
It's an improvement, but we're still not there:
$ mkdir -p d/e/f; ln -s d s; rm -r s/
rm: cannot remove 's/': Not a directory
[Exit 1]
$ find
.
./s
./d
Notice how
On 09/03/2012 10:29 AM, Linda Walsh wrote:
Coreutils has already implemented an exception for the root
directory: --no-preserve-root (whatever this would be useful
for except investigating what'd happen in a VM ...).
---
And by doing so has violated posix, since it doesn't say that if
a
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
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
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
I'm not sure what the rational for putting in special check to
try to remove the current directory *before*, it's children is,
but it's not correct behavior.
It used to be it just 'ignored' an attempt to delete the current dir
and deleted all the files under it.
Now there seems to be a
Linda Walsh wrote:
Now there seems to be a special check for . and disallow it as a
rm target. But that was a safe and portable way to delete all contents.
...
I would expect it to delete all but the current inode I'm parked on, and
for it -- either issue an error or silently ignore ...
58 matches
Mail list logo
