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
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
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 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 -
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
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
49 matches
Mail list logo
