Alan Curry wrote:
SGI is dead, Sun is dead, the game's over, we're the winners, and our rm has
been this way forever.
Until you learn that you are played off by your masters against
others, and that the only real win is a win-win, you are just a losing
pawn in a game.
I don't t
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 b
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
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
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 remo
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 d
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 ..
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.
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.
Ye
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, an
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, (I'm
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
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 n
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 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 itse
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
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 bee
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
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 dir
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 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 woul
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 behavior
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 n
On 09/07/2012 08:31 AM, Linda Walsh wrote:
> I wouldn't be opposed to adding it in addition,
Adding what in addition to what? Adding a --long-option is fine.
Adding an env-var is controversial. Stick to just one addition.
> but I don't want the extra
> typing for what is the more common case f
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. Bu
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 compati
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, or
Bernhard Voelker wrote:
On September 6, 2012 at 12:56 PM Linda Walsh 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. Peop
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 c
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, may
On September 6, 2012 at 12:56 PM Linda Walsh 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 would curse
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 accident
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
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 ."
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
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
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 EPER
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
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 ensur
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 it did travers
Eric Blake wrote:
POSIX does indeed say that, but it applies only when you use 'rm' in a
standards-compliant invocation; the moment you add --no-preserve-root to
your invocation, you are no longer using a standards-compliant
invocation, so all bets are off as far as POSIX goes.
--
Whic
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
Bernhard Voelker wrote:
> 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
>>
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
>
> N
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
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:
> 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 confirm
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 wit
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 f
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 `/proc/self/c
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 wit
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 t
Linda Walsh 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
an operand reso
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 -
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
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
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 l
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 argume
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
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
Linda Walsh wrote:
> 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.
I se
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...)
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 ..
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 special
64 matches
Mail list logo
