GNU bug report logs -
#12339
Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Previous Next
Reported by: Linda Walsh <coreutils <at> tlinx.org>
Date: Mon, 3 Sep 2012 00:34:02 UTC
Severity: normal
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12339 in the body.
You can then email your comments to 12339 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 00:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Linda Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Mon, 03 Sep 2012 00:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 check for "." and disallow it as a
rm target. But that was a safe and portable way to delete all contents.
can't use '*', -- it is expanded differently depending on shell and
settings!
I always felt a bit safer if I was able to cd into the dir I wanted, then
rm -fr from the root of that dir by specifying '.'
Could that be added back in as a safe and portable way to do rm *, where I
don't have to worry about whether or not it applies the * will pick up
hidden files.
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 ... preferring 'DoWIMean'
versus 'technically'...as being more user friendly.
Sides -- it normally does depth-first traversal --- since you can't delete
a dir with contents still in it -- so why different for '.'?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 03:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 ... preferring 'DoWIMean'
> versus 'technically'...as being more user friendly.
>
> Sides -- it normally does depth-first traversal --- since you can't delete
> a dir with contents still in it -- so why different for '.'?
+1. Feels like a bug to me.
Workaround:
find . -delete
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 06:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 12339 <at> debbugs.gnu.org (full text, mbox):
> 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...)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 07:30:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 see from your mention of "." below that you are objecting
to rm's refusal to remove "." or "..".
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
$ rm -rf .; rm --version | head -1
rm: cannot remove `.' or `..'
rm (GNU fileutils) 3.16
> 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.
>
> can't use '*', -- it is expanded differently depending on shell and settings!
>
> I always felt a bit safer if I was able to cd into the dir I wanted, then
> rm -fr from the root of that dir by specifying '.'
POSIX requires rm to reject any attempt to delete an explicitly specified
"." or ".." argument (or any argument whose last component is one of those):
http://pubs.opengroup.org/onlinepubs/000095399/utilities/rm.html
> Could that be added back in as a safe and portable way to do rm *, where I
> don't have to worry about whether or not it applies the * will pick up
> hidden files.
I suggest you use Bob's suggestion:
find . -delete
> 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 ... preferring 'DoWIMean'
> versus 'technically'...as being more user friendly.
>
> Sides -- it normally does depth-first traversal --- since you can't delete
> a dir with contents still in it -- so why different for '.'?
Safety, I suspect. "." and ".." may not mean anything to a novice.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 07:53:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 HP-UX 11.11, a now rather old release
from twelve years ago in 2000, the oldest easily available to me, and
got this:
$ /usr/bin/rm -rf .
rm: cannot remove .. or .
So I guess GNU coreutils is in good company with traditional Unix
systems! It has definitely been that way for a long time.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 08:20:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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):
>
> Hmm... Wow. I decided to check HP-UX 11.11, a now rather old release
> from twelve years ago in 2000, the oldest easily available to me, and
> got this:
>
> $ /usr/bin/rm -rf .
> rm: cannot remove .. or .
>
> So I guess GNU coreutils is in good company with traditional Unix
> systems! It has definitely been that way for a long time.
Linux has the ability to actually remove a directory that is empty but still
referenced as the cwd of some process. This ability is non-traditional
(my fuzzy memory says it showed up some time in the 2.2 or 2.4 era). It's
worth considering whether this change should be reflected by a relaxation of
rm's traditional behavior.
rm -rf $PWD, meaning basically the same thing as rm -rf ., works, and leaves
you in a directory so empty that ls -a reports no "." or ".." entries, and no
file can be created in the current directory. (open and stat and chdir still
work on . and .. though. They're magic.)
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 08:27:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 component is one of those):
>
> Hmm... Wow. I decided to check HP-UX 11.11, a now rather old release
> from twelve years ago in 2000, the oldest easily available to me, and
> got this:
>
> $ /usr/bin/rm -rf .
> rm: cannot remove .. or .
>
> So I guess GNU coreutils is in good company with traditional Unix
> systems! It has definitely been that way for a long time.
Seconded!
SunOS 5.9:
$ rm -rf .
$ rm -r .
rm of . is not allowed
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 08:34:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 of those):
>>
>> Hmm... Wow. I decided to check HP-UX 11.11, a now rather old release
>> from twelve years ago in 2000, the oldest easily available to me, and
>> got this:
>>
>> $ /usr/bin/rm -rf .
>> rm: cannot remove .. or .
>>
>> So I guess GNU coreutils is in good company with traditional Unix
>> systems! It has definitely been that way for a long time.
>
> Linux has the ability to actually remove a directory that is empty but still
> referenced as the cwd of some process. This ability is non-traditional
> (my fuzzy memory says it showed up some time in the 2.2 or 2.4 era). It's
> worth considering whether this change should be reflected by a relaxation of
> rm's traditional behavior.
I see very little benefit in relaxing this restriction.
Why introduce an incompatibility (slightly dangerous, even) with POSIX
and with such long-standing behavior?
> 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"
> you in a directory so empty that ls -a reports no "." or ".." entries, and no
> file can be created in the current directory. (open and stat and chdir still
> work on . and .. though. They're magic.)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 08:43:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 has fixed that particular Bourne shell
design error.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 08:51:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 I'm in zsh which has fixed that particular Bourne shell
> design error.
I use zsh on the command line, too (Go zsh! :-), but few have the luxury
of being able to target zsh as their sole bourne-like shell interpreter.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 14:37:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 message or
not.
> POSIX requires rm to reject any attempt to delete an explicitly specified
> "." or ".." argument (or any argument whose last component is one of those):
>
> http://pubs.opengroup.org/onlinepubs/000095399/utilities/rm.html
---
But you fail to follow the earlier stated POSIX
requirement:
..
" If this fails for any reason, rm shall write a diagnostic message to standard
error, do nothing more with the current file, and go on to any remaining files."
Specifically, in regards to a failure to remove a directory:
For each entry contained in file, other than dot or dot-dot, the four steps
listed here (1 to 4) shall be taken with the entry as if it were a file operand.
The rm utility shall not traverse directories by following symbolic links into
other parts of the hierarchy, but shall remove the links themselves."
So for each entry in ".", except for . and .., rm is to traverse and remove them
even after encountering an error -- which normally, it would only encounter at the
end of removing all files in the directory.
>>
>> Sides -- it normally does depth-first traversal --- since you can't delete
>> a dir with contents still in it -- so why different for '.'?
>
> Safety, I suspect. "." and ".." may not mean anything to a novice.
----
Again, ".." isn't the issue anymore than it should be skipped.
What is at issue is the order of deletion (depth first), and
it's not continuing to delete the other entires in the 'file' other
than "." and ".." after encountering any errors (including a rejection
to delete . and ..).
So the error message is fine.
But not deleting everything else in the dir isn't (at least
judging from the POSIX doc you pointed me at... -- Thanks for
the reference!
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 14:57:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 12339 <at> debbugs.gnu.org (full text, mbox):
Linda Walsh <coreutils <at> 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
an operand resolves to the root directory, rm shall write a
diagnostic message to standard error and do nothing more with such
operands.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 15:50:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 standard error and do nothing more with such
> operands.
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 ...).
So it'd be possible to have another new switch to exceptionally
permit removing ".", although - again - I don't see much gain
over `rm -rf "$PWD"` or `find . -delete`.
-1 from me.
Moreover, I'd remove support for --[no-]preserve-root in rm:
preserving is mandatory by POSIX, and not preserving is senseless.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 16:32:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 with such
> operands.
---
You are right.
This only further cements the worthlessness of the 2003 revision in it's
claim as being a POSIX standard.
The problem is that the initial standard didn't have many of these restrictions.
I don't know about this specific one, but I bet it wasn't in *THE*
POSIX standard.
The idea of a POSIX standard was to make things compatible and provide
a set of features for portable execution. Later revisions have mostly
about adding restrictions.
Most recently I observed a discussion on one of the posix lists about
how further screw with people by restricting filename chars from
the current set [^/\000] to [^/\000-\040]: "No more file names like this".
This showed the braindead nature of the poster who forgot to restrict
non-printing chars further up in the unicode range.
-------------
Voelker, Bernhard wrote:
> 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 standard error and do nothing more with such
>> operands.
>
> 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 switch is present, you can override the 2nd paragraph. If we
are going to be stricly posix, it says if the arg is the root
directory -- the util must have nothing more to do with the operand.
Adding special "except if this", options doesn't make it posix
compatible.
It's interesting how people can rationalize that's it's ok to
violate the standard for their special pet case, but when it comes
to one's proposed by someone else, it's all "nope, not sorry -- and
we can't remove _my_ feature for backwards compat reasons.."...
Obviously, the same workaround that was prescribed for working
around . would work for "/", namely: 'find / -delete'.
If you are are going to rigidly adhere to a broken standard that is
becoming more broken and restricted over time, you can't put in
pet exceptions while using POSIX compat as a justification for
not allowing other, more user friendly, options.
so +1 to Bernhard for point that out, but a -1 to those who
don't cite posix as an excuse, yet allow overrides that are non posix.
More generally, -1 to the bad trend of taking a portable OS Exchange
specification and turning it into a list of "thou shalt not's"...
As if we need another list of those... The first has been a great
excuse for oppression and mass murder... I wonder how high people
elevate the holy P.O.S.ix. :-(
---
Hey, I know... lets just add a new util 'r', does the job of
rm and rmdir combined w/o unnecessary posix restrictions.
r -f .
(automatically does what is needed to remove "." -- including files
beneath it).
Interesting fact -- MS's "netsh", allows you to type the minimum
number of chars of a command that are unambiguous to execute it.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Mon, 03 Sep 2012 20:07:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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/cwd': Too many levels of symbolic links
$ rm -fr /proc/self/cwd/.
rm: cannot remove directory: `/proc/self/cwd/.'
$ ls
foo
Aren't these bugs, at least?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 05:23:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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
> $ rm -fr /proc/self/cwd/
> rm: cannot remove `/proc/self/cwd': Too many levels of symbolic links
That is in rm_fts():
/* Perform checks that can apply only for command-line arguments. */
if (ent->fts_level == FTS_ROOTLEVEL)
{
if (strip_trailing_slashes (ent->fts_path))
ent->fts_pathlen = strlen (ent->fts_path);
ent->fts_path is stripped from /proc/self/cwd/ to /proc/self/cwd.
Then this:
Ternary is_empty_directory;
enum RM_status s = prompt (fts, ent, true /*is_dir*/, x,
PA_DESCEND_INTO_DIR, &is_empty_directory);
if (s == RM_OK && is_empty_directory == T_YES)
{
/* When we know (from prompt when in interactive mode)
that this is an empty directory, don't prompt twice. */
s = excise (fts, ent, x, true);
fts_skip_tree (fts, ent);
}
s is RM_OK, but is_empty_directory is T_NO, because it's no DIR ...
The FTS loop continues and diagnoses ELOOP. That's the strace output:
newfstatat(AT_FDCWD, "/proc/self/cwd/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/proc/self/cwd", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 ELOOP (Too many levels of
symbolic links)
openat(AT_FDCWD, "/proc/self/cwd", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 ELOOP (Too many levels of
symbolic links)
unlinkat(AT_FDCWD, "/proc/self/cwd", AT_REMOVEDIR) = -1 EACCES (Permission denied)
The example applies to all symlinks to directories (i.e. not only
to /proc/self/cwd):
$ mkdir d
$ touch d/file
$ ln -s d dl
$ rm -rv dl/
/home/berny/cu/src/rm: cannot remove ‘dl’: Too many levels of symbolic links
However, in this case, unlinkat returns ENOTDIR:
unlinkat(AT_FDCWD, "dl", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
> $ rm -fr /proc/self/cwd/.
> rm: cannot remove directory: `/proc/self/cwd/.'
> $ ls
> foo
That's the dot case.
> Aren't these bugs, at least?
The latter: no, because dot must not be removed.
The former: maybe, but the question is what rm should remove:
the symlink or the target? The info page is quiet about this.
I tend to say it's okay as it is, because if someone wants to
remove the target of a symlink,(s)he can always to
$ rm -rv $(readlink -f dl)
Only the diagnostic (ELOOP) looks a bit strange ...
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 05:34:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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
Solaris 11 'rm':
$ mkdir d
$ touch d/file
$ ln -s d dl
$ ls -al *
lrwxrwxrwx 1 eggert faculty 1 Sep 3 22:26 dl -> d
d:
total 16
drwxrwxr-x 2 eggert faculty 178 Sep 3 22:26 .
drwxrwxr-x 3 eggert faculty 234 Sep 3 22:26 ..
-rw-rw-r-- 1 eggert faculty 0 Sep 3 22:26 file
$ rm -r dl/
$ ls -al *
lrwxrwxrwx 1 eggert faculty 1 Sep 3 22:26 dl -> d
Thanks for reminding me about "." and explaining
why the other example is not a bug.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 10:43:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 the bug does not occur with
> Solaris 11 'rm':
>
> $ mkdir d
> $ touch d/file
> $ ln -s d dl
> $ ls -al *
> lrwxrwxrwx 1 eggert faculty 1 Sep 3 22:26 dl -> d
Same for FreeBSD 9.0-RELEASE-p3:
freebsd$ mkdir d; ln -s d s; /bin/rm -r s/; ls
s@
But not with busybox 1.20.0-6:
$ mkdir d; ln -s d s; busybox rm -r s/; ls
d/
I have mixed feelings, but am leaning towards the
Solaris 11/FreeBSD behavior.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 10:49:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 12:56:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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/
> rm: cannot remove `/proc/self/cwd': Too many levels of symbolic links
> $ rm -fr /proc/self/cwd/.
> rm: cannot remove directory: `/proc/self/cwd/.'
> $ ls
> foo
>
> Aren't these bugs, at least?
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 traverse s/ into d/, and removed d/e and d/e/f.
The only problem is that when it attempted to remove the command-line
specified "s/", unlinkat (AT_FDCWD, "s/", AT_REMOVEDIR) failed:
unlinkat(4, "d", 0) = 0
unlinkat(5, "f", AT_REMOVEDIR) = 0
unlinkat(4, "e", AT_REMOVEDIR) = 0
unlinkat(AT_FDCWD, "s/", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
rm: cannot remove 's/': Not a directory
+++ exited with 1 +++
Now, this looks like a problem with unlinkat.
Debating whether to add a test.
Just writing the above, I know the answer. I will add a test.
==================================================================
From 958c553a84d37bdd8669ae68bfc8c4d4c5e7d2e1 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Tue, 4 Sep 2012 14:40:11 +0200
Subject: [PATCH] rm: avoid bogus diagnostic for a slash-decorated
symlink-to-dir
These commands would evoke an invalid diagnostic:
$ mkdir d && ln -s d s && env rm -r s/
rm: cannot remove 's': Too many levels of symbolic links
remove.c was stripping trailing slashes from "s/" before passing
the name to "rm". But a trailing slash may change the semantics,
and thus should not be stripped.
* src/remove.c (rm_fts): Do not strip trailing slashes.
* tests/rm/v-slash.sh: Adapt to new expected output.
* gnulib: Update to latest, for an improved fts.c that merely
normalizes trailing slashes.
Reported by Paul Eggert in discussion of http://bugs.gnu.org/12339
---
gnulib | 2 +-
src/remove.c | 3 ---
tests/rm/v-slash.sh | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/gnulib b/gnulib
index 68f693f..3a9002d 160000
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 68f693ff1db33bf24695f0f42c62e7801966fd06
+Subproject commit 3a9002d3cc63da7110f133b1040d2d2b0aad8305
diff --git a/src/remove.c b/src/remove.c
index 69faae6..847a5cc 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -433,9 +433,6 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
/* Perform checks that can apply only for command-line arguments. */
if (ent->fts_level == FTS_ROOTLEVEL)
{
- if (strip_trailing_slashes (ent->fts_path))
- ent->fts_pathlen = strlen (ent->fts_path);
-
/* If the basename of a command line argument is "." or "..",
diagnose it and do nothing more with that argument. */
if (dot_or_dotdot (last_component (ent->fts_accpath)))
diff --git a/tests/rm/v-slash.sh b/tests/rm/v-slash.sh
index 504f4ff..ec77bd0 100755
--- a/tests/rm/v-slash.sh
+++ b/tests/rm/v-slash.sh
@@ -26,7 +26,7 @@ touch a/x || framework_failure_
rm --verbose -r a/// > out || fail=1
cat <<\EOF > exp || fail=1
removed 'a/x'
-removed directory: 'a'
+removed directory: 'a/'
EOF
compare exp out || fail=1
--
1.7.12.176.g3fc0e4c
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 14:30:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 it did traverse s/ into d/, and removed d/e and d/e/f.
> The only problem is that when it attempted to remove the command-line
> specified "s/", unlinkat (AT_FDCWD, "s/", AT_REMOVEDIR) failed:
>
> unlinkat(4, "d", 0) = 0
> unlinkat(5, "f", AT_REMOVEDIR) = 0
> unlinkat(4, "e", AT_REMOVEDIR) = 0
> unlinkat(AT_FDCWD, "s/", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
> rm: cannot remove 's/': Not a directory
> +++ exited with 1 +++
>
> Now, this looks like a problem with unlinkat.
Hmm, what about dereferencing command line symlinks with trailing
slashes _before_ entering the FTS loop instead?
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 15:03:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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
>> .
>> ./s
>> ./d
>>
>> Notice how it did traverse s/ into d/, and removed d/e and d/e/f.
>> The only problem is that when it attempted to remove the command-line
>> specified "s/", unlinkat (AT_FDCWD, "s/", AT_REMOVEDIR) failed:
>>
>> unlinkat(4, "d", 0) = 0
>> unlinkat(5, "f", AT_REMOVEDIR) = 0
>> unlinkat(4, "e", AT_REMOVEDIR) = 0
>> unlinkat(AT_FDCWD, "s/", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
>> rm: cannot remove 's/': Not a directory
>> +++ exited with 1 +++
>>
>> Now, this looks like a problem with unlinkat.
>
> Hmm, what about dereferencing command line symlinks with trailing
> slashes _before_ entering the FTS loop instead?
Thanks, but I'm pretty sure that would be too much work to perform
on any slash-decorated operand.
Besides, I'm not 100% sold on the idea that that final unlinkat
call should be creating a dangling symlink (i.e., by removing
the directory to which "s" points).
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 15:40:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/04/2012 08:02 AM, Jim Meyering wrote:
> I'm not 100% sold on the idea that that final unlinkat
> call should be creating a dangling symlink (i.e., by removing
> the directory to which "s" points).
But that's what rmdir() and the rmdir command
are supposed to do. That much, at least, is pretty clearly
specified by POSIX 2008.
But now I see that coreutils rmdir doesn't do that:
$ mkdir a
$ ln -s a b
$ rmdir b/
rmdir: failed to remove 'b/': Not a directory
Solaris 10 rmdir gets it right. Interestingly enough,
Solaris 10's port of coreutils rmdir (/opt/sfw/bin/rmdir)
also gets it right: it executes rmdir("b/"),
which removes the directory. This is coreutils 5.93,
so I assume at some point there was a regression?
A bit more investigation shows that rmdir("b/")
fails on Linux 3.2.0, succeeds on Solaris 10, but
fails on Solaris 11! Curiouser and curiouser. This
means the Solaris 11 rmdir command agrees with GNU/Linux
and they both disagree with POSIX and with Solaris 10.
The problem also affects other commands. For example,
POSIX says this should work:
$ mkdir a
$ ln -s a b
$ mv b/ c
and should rename a to c. It does work, on Solaris 11,
but with coreutils it fails and reports
mv: cannot move 'b/' to 'c': Not a directory
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 17:47:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 12339 <at> debbugs.gnu.org (full text, mbox):
Jim Meyering wrote:
> These commands would evoke an invalid diagnostic:
> $ mkdir d && ln -s d s && env rm -r s/
> rm: cannot remove 's': Too many levels of symbolic links
> remove.c was stripping trailing slashes from "s/" before passing
> the name to "rm". But a trailing slash may change the semantics,
> and thus should not be stripped.
>
I would assert that the trailing "." shouldn't be stripped either.
If the directory is a mount point -- then "." would indicate the
contents of the mount point -- being after the "/", while the "/" would be
the mount point itself.
In my case, I wanted to delete everything in the mount point. Removal
of the mount point itself would ideally unmount the 'fs', but I won't hold
my breath on that one (and leave the root inode of the file system in
the unmounted file system -- thus I've effectively removed "." from
mountpoint/.
Which is different from the "." of a directory entry -- NO I'm not
asking for this as a feature, I'm just saying it would be a valid semantic
paradigm"). I WOULD want rm dir foobar/. to remove all contents in the
directory before failing on ".". The original version of posix didn't have
this restriction/problem. POSIX is portability standard -- it should not
be regarded as a restrictive standard, unless not doing so would hinder
portability. In effect, they are disallowing OS's to make extensions beyond
what they allow in the newer standards...
That goes WAY beyond a portability standard...
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 17:50:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/04/2012 11:46 AM, Linda A. Walsh wrote:
> POSIX is portability standard -- it should not
> be regarded as a restrictive standard, unless not doing so would hinder
> portability. In effect, they are disallowing OS's to make extensions
> beyond
> what they allow in the newer standards...
That's where you are wrong. POSIX _does_ allow OS's to make extensions
beyond the standard.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 17:54:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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,
and there's an argument for not departing from the standard
unless there's a good reason.
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/."
doesn't do what you want. After all, the version without the
"." is easier to type, and it's more convenient with shells
that autocomplete, so the fact that POSIX requires failure for
the version with the "." shouldn't be that big a deal.
("rm -fr foo/" doesn't work right either, but we're
looking into that....)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 17:59:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 switch is present, you can override the 2nd paragraph.
Unfortunately, you are wrong on your interpretation of POSIX. POSIX
specifically allows implementations to add extensions, such as
--no-preserve-root, and that such extensions may explicitly override the
required behavior for the application when no extensions are used.
After all, that's what extensions are for. In other words, coreutils is
_not_ violating POSIX by adding --no-preserve-root as an extension.
> If we
> are going to be stricly posix, it says if the arg is the root
> directory -- the util must have nothing more to do with the operand.
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.
>
> If you are are going to rigidly adhere to a broken standard that is
> becoming more broken and restricted over time, you can't put in
> pet exceptions while using POSIX compat as a justification for
> not allowing other, more user friendly, options.
If you are going to continually gripe about POSIX rather than
constructively contribute towards improving it, then we have no reason
to pay attention to your gripes. You can become a member of the Austin
Group at no monetary cost, and contribute bug reports to places where
you think the standard has got things wrong. But griping to the
coreutils list is not the way to get POSIX fixed.
If, on the other hand, you are arguing for more long-option extensions
to coreutils, then please contribute patches rather than gripes.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 18:08:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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.
--
Which under GNU tools has mean when POSIX_CORRECTLY=1 is set
in the environment.
It is not.
There is nothing preventing tools functioning in a more userfriendly
manner than POSIX allows in the absence of a request for POSIX_CORRECTLY.
Unless you are telling me that all GNU utils have removed
that and always run in POSIX mode by default.
POSIX was designed to be a lowest common denominator --
not a highest level allowed -- that's why under Gnu/Linux it's
only under a specific request for POSIX compat that lowest level
functionality is enforced.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Tue, 04 Sep 2012 23:23:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 00:50:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/04/2012 04:21 PM, Linda A. Walsh wrote:> Paul Eggert wrote:
> expecting it to do nothing useful other than issue an error?
Sure. People might expect the utility to complain about
what they consider to be obvious typos, rather than to
remove files they don't expect to be removed. For example:
rm -fr .*
safely removes all file names beginning with "." in the
working directory, without inadvertently removing file names
that do not begin with ".", or files in the parent
directory. I can see people being used to this sort of
thing, and being annoyed greatly if we change it.
> Ok, will foo/ remove the contents only and not the directory?
No, "rm -fr foo/" removes the directory too.
> It seems so fragile -- because some utils require the /. to make
> sure you don't ALSO remove the directory.
Which utilities are those? The standard POSIX style is that
foo/ names the directory.
> However, adding foo/ -- does that imply that ./ will also work?
No, "./" is treated as ".". Sorry.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 01:57:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> On 09/04/2012 04:21 PM, Linda A. Walsh wrote:> Paul Eggert wrote:
>
>
>> expecting it to do nothing useful other than issue an error?
>>
>
> Sure. People might expect the utility to complain about
> what they consider to be obvious typos, rather than to
> remove files they don't expect to be removed. For example:
>
> rm -fr .*
>
> safely removes all file names beginning with "." in the
> working directory, without inadvertently removing file names
> that do not begin with ".", or files in the parent
> directory. I can see people being used to this sort of
> thing, and being annoyed greatly if we change it.
>
----
i wouldn't regard that as safe.
I always use rm -fr .[^.]*
Why is that interfaces must sync to the lowest level.
unix was NOT supposed to be that way.
>
>> Ok, will foo/ remove the contents only and not the directory?
>>
>
> No, "rm -fr foo/" removes the directory too.
>
So how do delete all files in the directory without wild cards?
(as you don't know how or if they will be expanded).
(only VERY recently has bash included "." in "*" -- it used to be
ignored and
still is if you have flags set to ignore it.
Shells don't consistently expand wildcards, and the OS doesn't expand them
at all (i.e. when passed in 'exec')...
This is what I mean about useful features being removed in order to dumb
down
the interface -- as dir/" also tries to remove the dir... which isn't
likely to work on a mount point.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 06:26:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/04/2012 06:55 PM, Linda A. Walsh wrote:
> So how do delete all files in the directory without wild cards?
Why tie your hands behind your back? Use wild cards:
cd DIRECTORY && rm -fr * .[!.] .??*
If you do this a lot, put it into a shell script.
It's not like the need is all that common, for most people,
but if you need it that's what scripts are for.
If you fiddle with your shell settings about
how wildcards are expanded, make
sure your script does wildcards in the standard way.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 06:42:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/05/2012 08:25 AM, Paul Eggert wrote:
> On 09/04/2012 06:55 PM, Linda A. Walsh wrote:
>
>> So how do delete all files in the directory without wild cards?
>
> Why tie your hands behind your back? Use wild cards:
>
> cd DIRECTORY && rm -fr * .[!.] .??*
>
> If you do this a lot, put it into a shell script.
> It's not like the need is all that common, for most people,
> but if you need it that's what scripts are for.
>
> If you fiddle with your shell settings about
> how wildcards are expanded, make
> sure your script does wildcards in the standard way.
Exactly, we're now at the point where globbing is the topic,
much way away from coreutils and rm.
Bash knows dotglob:
$ mkdir d ; cd d
$ touch .a b ; mkdir c
$ ( shopt -s dotglob ; rm -rv * )
removed `.a'
removed `b'
removed directory: `c'
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 06:59:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> On 09/04/2012 06:55 PM, Linda A. Walsh wrote:
>
>
>> So how do delete all files in the directory without wild cards?
>>
>
> Why tie your hands behind your back? Use wild cards:
>
> cd DIRECTORY && rm -fr * .[!.] .??*
>
> If you do this a lot, put it into a shell script.
> It's not like the need is all that common, for most people,
> but if you need it that's what scripts are for.
>
> If you fiddle with your shell settings about
> how wildcards are expanded, make
> sure your script does wildcards in the standard way.
>
---
I'm not talking for interactive use... I'm talking for use in a script
that might run on systems that are not mine -- so I can't rely on shell
settings.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 14:36:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/04/2012 11:58 PM, Linda A. Walsh wrote:
> I'm not talking for interactive use... I'm talking for use in a script
> that might run on systems that are not mine -- so I can't rely on shell settings.
Yes you can. Just start the script with "#!/bin/sh", as usual.
When invoked that way, Bash and other shells are POSIX-compliant
in this area.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 14:52:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> On 09/04/2012 11:58 PM, Linda A. Walsh wrote:
>
>> I'm not talking for interactive use... I'm talking for use in a script
>> that might run on systems that are not mine -- so I can't rely on shell settings.
>>
>
> Yes you can. Just start the script with "#!/bin/sh", as usual.
> When invoked that way, Bash and other shells are POSIX-compliant
> in this area.
>
To what level of posix... if they are compliant to the original level
then they might have the original behavior that allowed rm -r . to work.
if they are the 2003 version, then a different way, .. bleh.
I overly worry about things that don't occur, but get caught
by things I didn't worry enough about. So it doesn't really
matter. I just preferred simplicity to the ever changing
posix.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 14:52:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 traverse s/ into d/, and removed d/e and d/e/f.
> The only problem is that when it attempted to remove the command-line
> specified "s/", unlinkat (AT_FDCWD, "s/", AT_REMOVEDIR) failed:
>
> unlinkat(4, "d", 0) = 0
> unlinkat(5, "f", AT_REMOVEDIR) = 0
> unlinkat(4, "e", AT_REMOVEDIR) = 0
> unlinkat(AT_FDCWD, "s/", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
> rm: cannot remove 's/': Not a directory
> +++ exited with 1 +++
>
> Now, this looks like a problem with unlinkat.
That's probably a problem with unlinkat,
but does not explain what caused the invalid diagnostic.
BTW, while it was easy for me to discover that this bug
was introduced between 8.5 and 8.6, neither rm.c nor remove.c
had significant changes in that delta.
And bisecting would have been a chore, since bootstrapping those versions
is, um... challenging. That made me want to make each package in the
volatile tool chain (m4, autoconf, automake and maybe even bison, too)
into a submodule of coreutils. Currently it's trivial to build coreutils
from a tarball, but it's not at all easy to bootstrap from an arbitrary
version in git.
Anyway, I ended up comparing strace output from 8.5's rm to that of
the rm from 8.6. Here's the key difference:
-openat(AT_FDCWD, "s", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY) = 3
+openat(AT_FDCWD, "s", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 ELOOP (Too many levels of symbolic links)
...
unlinkat(AT_FDCWD, "s", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory)
The directory-opening code in gnulib's fts.c, which rm uses for
recursive traversal, was fixed to avoid a race condition:
commit 0971365ee6f6638cbeec77db08fbdfe5f3bab53d
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Mon Sep 13 12:38:41 2010 -0700
fts: use O_NOFOLLOW to avoid race condition when opening a directory
* lib/fts.c (opendirat): New arg extra_flags.
(__opendir2): Use it to avoid following symlinks when opening
a directory, if symlinks are not supposed to be followed. See
<http://lists.gnu.org/archive/html/bug-gnulib/2010-09/msg00213.html>.
That was clearly a good change.
What it did however, was to trigger a problem in remove.c,
making it print this bogus diagnostic:
rm: cannot remove 's': Too many levels of symbolic links
Here's the bad code:
/* When failing to rmdir an unreadable directory, the typical
errno value is EISDIR, but that is not as useful to the user
as the errno value from the failed open (probably EPERM).
Use the earlier, more descriptive errno value. */
if (ent->fts_info == FTS_DNR)
errno = ent->fts_errno;
error (0, errno, _("cannot remove %s"), quote (ent->fts_path));
The fts change affected this code by making the "if" condition true.
Before, the openat succeeded. Now, it fails with ELOOP.
By telling openat not to follow symlinks, we've made fts set ->fts_info
to FTS_DNR (unreadable directory), and that made remove.c use the
prior errno value (the bogus ELOOP).
While not necessary to fix the problem at hand, since I made
it so the trailing slash is preserved down to the openat syscall,
this additional change might avoid a similar problem down the road:
- /* When failing to rmdir an unreadable directory, the typical
- errno value is EISDIR, but that is not as useful to the user
- as the errno value from the failed open (probably EPERM).
- Use the earlier, more descriptive errno value. */
- if (ent->fts_info == FTS_DNR)
+ /* 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 earlier, more descriptive errno value. */
+ if (ent->fts_info == FTS_DNR
+ && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
+ && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
errno = ent->fts_errno;
error (0, errno, _("cannot remove %s"), quote (ent->fts_path));
mark_ancestor_dirs (ent);
I'll post this new pair of rm-related patches in a minute.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 14:57:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 ensure that if it fails, it does not fail
with the ELOOP message, but that seems way too weak.
From 57dd06703cb89ba53d05af95c11e89a2ca51af5c Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Tue, 4 Sep 2012 14:40:11 +0200
Subject: [PATCH 1/2] rm: avoid bogus diagnostic for a slash-decorated
symlink-to-dir
These commands would evoke an invalid diagnostic:
$ mkdir d && ln -s d s && env rm -r s/
rm: cannot remove 's': Too many levels of symbolic links
remove.c was stripping trailing slashes from "s/" before passing
the name to "rm". But a trailing slash may change the semantics,
and thus should not be stripped.
* src/remove.c (rm_fts): Do not strip trailing slashes.
* tests/rm/v-slash.sh: Adapt to new expected output.
* gnulib: Update to latest, for an improved fts.c that merely
normalizes trailing slashes.
Reported by Paul Eggert in discussion of http://bugs.gnu.org/12339
---
NEWS | 4 ++++
gnulib | 2 +-
src/remove.c | 3 ---
tests/rm/v-slash.sh | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index f3874fd..a848ffe 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,10 @@ GNU coreutils NEWS -*- outline -*-
than ignoring the -d option and failing with an 'Is a directory' error.
[bug introduced in coreutils-8.19, with the addition of --dir (-d)]
+ rm -r S/ (where S is a symlink-to-directory) no longer gives the invalid
+ "Too many levels of symbolic links" diagnostic.
+ [bug introduced in coreutils-8.6]
+
** Improvements
stat and tail work better with ZFS. stat -f --format=%T now reports the
diff --git a/gnulib b/gnulib
index 68f693f..3a9002d 160000
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 68f693ff1db33bf24695f0f42c62e7801966fd06
+Subproject commit 3a9002d3cc63da7110f133b1040d2d2b0aad8305
diff --git a/src/remove.c b/src/remove.c
index 69faae6..847a5cc 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -433,9 +433,6 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
/* Perform checks that can apply only for command-line arguments. */
if (ent->fts_level == FTS_ROOTLEVEL)
{
- if (strip_trailing_slashes (ent->fts_path))
- ent->fts_pathlen = strlen (ent->fts_path);
-
/* If the basename of a command line argument is "." or "..",
diagnose it and do nothing more with that argument. */
if (dot_or_dotdot (last_component (ent->fts_accpath)))
diff --git a/tests/rm/v-slash.sh b/tests/rm/v-slash.sh
index 504f4ff..ec77bd0 100755
--- a/tests/rm/v-slash.sh
+++ b/tests/rm/v-slash.sh
@@ -26,7 +26,7 @@ touch a/x || framework_failure_
rm --verbose -r a/// > out || fail=1
cat <<\EOF > exp || fail=1
removed 'a/x'
-removed directory: 'a'
+removed directory: 'a/'
EOF
compare exp out || fail=1
--
1.7.12.176.g3fc0e4c
From eda8c84778bc72192592b79724466946ca7def97 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Wed, 5 Sep 2012 16:48:50 +0200
Subject: [PATCH 2/2] rm: be more careful when using a replacement errno value
* src/remove.c (excise): Tighten the test for when we defer to an
old errno value: instead of relying solely on an FTS_DNR (unreadable
directory) failure, also test current and replacement errno values.
This change would also have solved the problem addressed by commit
v8.19-106-g57dd067. For more info, see http://bugs.gnu.org/12339#113
---
gnulib | 2 +-
src/remove.c | 12 +++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gnulib b/gnulib
index 3a9002d..68f693f 160000
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 3a9002d3cc63da7110f133b1040d2d2b0aad8305
+Subproject commit 68f693ff1db33bf24695f0f42c62e7801966fd06
diff --git a/src/remove.c b/src/remove.c
index 847a5cc..0c25462 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -392,11 +392,13 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir)
if (ignorable_missing (x, errno))
return RM_OK;
- /* When failing to rmdir an unreadable directory, the typical
- errno value is EISDIR, but that is not as useful to the user
- as the errno value from the failed open (probably EPERM).
- Use the earlier, more descriptive errno value. */
- if (ent->fts_info == FTS_DNR)
+ /* 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 earlier, more descriptive errno value. */
+ if (ent->fts_info == FTS_DNR
+ && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
+ && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
errno = ent->fts_errno;
error (0, errno, _("cannot remove %s"), quote (ent->fts_path));
mark_ancestor_dirs (ent);
--
1.7.12.176.g3fc0e4c
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 15:12:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 earlier, more descriptive errno value. */
> + if (ent->fts_info == FTS_DNR
> + && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
> + && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
Thanks for doing all that. I did notice that the code mentions
ENOTEMPTY but the comment doesn't -- is that intentional?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 15:14:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On 09/05/2012 07:51 AM, Linda A. Walsh wrote:
>> Just start the script with "#!/bin/sh", as usual.
>> When invoked that way, Bash and other shells are POSIX-compliant
>> in this area.
> To what level of posix...
To all the levels that are relevant for this discussion.
In practice, people use "#!/bin/sh" and it works pretty well
to avoid compatibility issues like this. It's not perfect
for all POSIX issues, but you were asking for a solution to
a particular problem, and this should solve your problem.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 15:19:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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
>> + or EACCES, use the earlier, more descriptive errno value. */
>> + if (ent->fts_info == FTS_DNR
>> + && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
>> + && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
>
> Thanks for doing all that. I did notice that the code mentions
> ENOTEMPTY but the comment doesn't -- is that intentional?
Yes. I considered whether to remove explicit mention of those errno
values in the comment for precisely that reason, but didn't bother.
Good point. I've relaxed the comment wording enough to permit other
explicit E* names:
diff --git a/src/remove.c b/src/remove.c
index 0c25462..a141718 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir)
if (ignorable_missing (x, errno))
return RM_OK;
- /* When failing to rmdir an unreadable directory, the typical errno value
- is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
+ /* When failing to rmdir an unreadable directory, we see errno values
+ like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic.
When that happens and the errno value from the failed open is EPERM
or EACCES, use the earlier, more descriptive errno value. */
if (ent->fts_info == FTS_DNR
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 20:23:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 failed open is EPERM
>>> + or EACCES, use the earlier, more descriptive errno value. */
>>> + if (ent->fts_info == FTS_DNR
>>> + && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
>>> + && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
>>
>> Thanks for doing all that. I did notice that the code mentions
>> ENOTEMPTY but the comment doesn't -- is that intentional?
>
> Yes. I considered whether to remove explicit mention of those errno
> values in the comment for precisely that reason, but didn't bother.
> Good point. I've relaxed the comment wording enough to permit other
> explicit E* names:
>
> diff --git a/src/remove.c b/src/remove.c
> index 0c25462..a141718 100644
> --- a/src/remove.c
> +++ b/src/remove.c
> @@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir)
> if (ignorable_missing (x, errno))
> return RM_OK;
>
> - /* When failing to rmdir an unreadable directory, the typical errno value
> - is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
> + /* When failing to rmdir an unreadable directory, we see errno values
> + like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic.
> When that happens and the errno value from the failed open is EPERM
> or EACCES, use the earlier, more descriptive errno value. */
> if (ent->fts_info == FTS_DNR
I've pushed the result:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=ccbd3f3b290cb1bb
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=57dd06703cb89ba5
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 05 Sep 2012 21:07:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 that allow me to shoot
myself in the foot if I really want to! ;-)
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 failed open is EPERM
>>> + or EACCES, use the earlier, more descriptive errno value. */
>>> + if (ent->fts_info == FTS_DNR
>>> + && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
>>> + && (ent->fts_errno == EPERM || ent->fts_errno == EACCES))
>> Thanks for doing all that. I did notice that the code mentions
>> ENOTEMPTY but the comment doesn't -- is that intentional?
>
> Yes. I considered whether to remove explicit mention of those errno
> values in the comment for precisely that reason, but didn't bother.
> Good point. I've relaxed the comment wording enough to permit other
> explicit E* names:
>
> diff --git a/src/remove.c b/src/remove.c
> index 0c25462..a141718 100644
> --- a/src/remove.c
> +++ b/src/remove.c
> @@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir)
> if (ignorable_missing (x, errno))
> return RM_OK;
>
> - /* When failing to rmdir an unreadable directory, the typical errno value
> - is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
> + /* When failing to rmdir an unreadable directory, we see errno values
> + like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic.
> When that happens and the errno value from the failed open is EPERM
> or EACCES, use the earlier, more descriptive errno value. */
> if (ent->fts_info == FTS_DNR
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 01:18:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> On 09/05/2012 07:51 AM, Linda A. Walsh wrote:
>
>>> Just start the script with "#!/bin/sh", as usual.
>>> When invoked that way, Bash and other shells are POSIX-compliant
>>> in this area.
>>>
>> To what level of posix...
>>
> To all the levels that are relevant for this discussion.
>
> In practice, people use "#!/bin/sh" and it works pretty well
> to avoid compatibility issues like this. It's not perfect
> for all POSIX issues, but you were asking for a solution to
> a particular problem, and this should solve your problem.
>
-----
Now I remember how I got here in the first place...
It was because of bash moving to the POSIX 2003 standard and breaking
many things I'd come to rely on, that I eventually realized that it was
unsuitable to rely on for programming. I had written a logical volume
snapshot generator and manager in about ~1500 lines of shell script
across multiple files -- mostly as a proof of concept -- but also because
it seemed simple and grew as I realized it was 90% error condition handling.
Bash got very unreliable in handling error conditions via "-e" w/the new
POSIX standard -- can't return non zero from a function (so no more
mathematical
functions), can't return non-zero from a calc (()) or let statement -- both
of which now trigger error exits under "-e" due to POSIX
More stuff happened, I decided to throw it away and rewrite in perl.
I'm still wanting to call rm -fr without wild cards to remove everything in
a directory.
One would think the "rm" utility which is *designed* to remove files
recursively, would do the task and NOT need the shell to do it's job.
My perl program has tried to call rm -fr . and *, neither of which work.
if rm can't remove all the files in a dir by itself -- I assert it is
failing
it's job as an 'rm' program. Removing files is it's sole job in life...
it can remove singles and directories... using rm -fr ./. or dir/. or . were
all ways of removing all contents under their targets without removing
the directory.
That feature is now gone.
So I'd like to request it be added when not operating under POSIX_CORRECTLY.
It's the right thing to do for the command line. We don't have so many
clueless
dweebs in a tty window -- most want point and click.
I know I don't want to call bash as a helper for rm -- as I know
with BASH_ENV, and such, it can very easily be running alot of overhead code
besides the simple rm function I wanted to do.
I think on many systems /bin/sh is a link to ash or dash, and no telling how
they will act/perform -- I don't want an extra dependency.
So should I start looking to write a patch for rm and possibly fork it?
Just realizing that I'm where I'm at today because of bash going POSIX has
left me pretty cold.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 03:26:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 be happy to put in the check for POSIX_CORRECTLY if you are amenable...
Note.. am not claiming this is the most efficient way to do it, but it
seemed to be the least impact on code I was new to.
Ishtar:packages/sources/coreutils-8.14> cat coreutils-8.14.remove.c.diff
--- src/remove.c 2011-10-10 00:56:46.000000000 -0700
+++ src/remove.c 2012-09-05 18:23:58.449319142 -0700
@@ -446,6 +446,20 @@
return RM_ERROR;
}
+
+static inline bool
+dotdot (char const *file_name)
+{
+ if (file_name[0] == '.' && file_name[1])
+ {
+ char sep = file_name[(file_name[1] == '.') + 1];
+ return (! sep || ISSLASH (sep));
+ }
+ else
+ return false;
+}
+
+
/* This function is called once for every file system object that fts
encounters. fts performs a depth-first traversal.
A directory is usually processed twice, first with fts_info == FTS_D,
@@ -476,7 +490,7 @@
/* If the basename of a command line argument is "." or "..",
diagnose it and do nothing more with that argument. */
- if (dot_or_dotdot (last_component (ent->fts_accpath)))
+ if (dotdot (last_component (ent->fts_accpath)))
{
error (0, 0, _("cannot remove directory: %s"),
quote (ent->fts_path));
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 06:57:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 and doing an "rm -fr ."
>
> I'll be happy to put in the check for POSIX_CORRECTLY if you are amenable...
> Note.. am not claiming this is the most efficient way to do it, but it
> seemed to be the least impact on code I was new to.
>
> Ishtar:packages/sources/coreutils-8.14> cat coreutils-8.14.remove.c.diff
> --- src/remove.c 2011-10-10 00:56:46.000000000 -0700
> +++ src/remove.c 2012-09-05 18:23:58.449319142 -0700
> @@ -446,6 +446,20 @@
> return RM_ERROR;
> }
>
> +
> +static inline bool
> +dotdot (char const *file_name)
> +{
> + if (file_name[0] == '.' && file_name[1])
> + {
> + char sep = file_name[(file_name[1] == '.') + 1];
> + return (! sep || ISSLASH (sep));
> + }
> + else
> + return false;
> +}
> +
> +
> /* This function is called once for every file system object that fts
> encounters. fts performs a depth-first traversal.
> A directory is usually processed twice, first with fts_info == FTS_D,
> @@ -476,7 +490,7 @@
>
> /* If the basename of a command line argument is "." or "..",
> diagnose it and do nothing more with that argument. */
> - if (dot_or_dotdot (last_component (ent->fts_accpath)))
> + if (dotdot (last_component (ent->fts_accpath)))
> {
> error (0, 0, _("cannot remove directory: %s"),
> quote (ent->fts_path));
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 accidentally ran
that command. Even if that were done only when POSIX_CORRECTLY were not
set, they would still be burned. Very few people ever set that envvar.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 10:57:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 accidentally ran
> that command.
---
Just like people who ran "rm -fr * in /" and didn't get their POSIX
mandated behavior, would curse you?
You are playing Mommy, to people and not allowing them to do what
they are asking the computer to do.
You disabling rm's ability to function. There is no way for it to
remove files in it's directory and not the current directory without
this patch. It cripples the program. To do the same job requires
use of auxiliary programs.
** Users would already be cursing those who deliberately crippled
** usability in the name of compatibility.
Unix didn't have Windows-ish mentality on the command line...
but wouldn't unix users curse those who brought such to the unix
command line?
"There needs to be someone willing to to step up for user
freedom, and Gnu used to be that... but it seems they are
becoming corrupt like every big organization" -- is that what
you wish to become Gnu's epitaph? Users who saw Gnu as
a freedom supporting symbol will see this as "selling-out"
functionality in order to become respectable.
You are claim users would curse not being able to get an error message
for something they deliberately type in.
Whereas I describe users who curse due to you removing
functionality. You really would rather support those
who are looking for error messages over those looking for
functionality? I would question the wisdom of taking
that approach, especially when you've been clearly called on it.
GNU needs to be clear their priorities -- maintaining software
freedom, or bowing down to corporate powers... POSIX isn't
a user group -- it's an enforcement arm of a Corporate
Entity that seeks to create a proprietary vision (it is owned
by them -- Unix, POSIX, The OpenGroup... are all owned by
the corporate entity who holds those as assets -- (see the legal
pages at their website:
like http://www.opengroup.org/content/legal-frequently-asked-questions).
Since when does Gnu put corporate interests before users?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 11:15:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 12339 <at> debbugs.gnu.org (full text, mbox):
On September 6, 2012 at 12:56 PM Linda Walsh <coreutils <at> 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 would curse us
> > for making GNU rm remove their precious files when they accidentally ran
> > that command.
> ---
>
> Just like people who ran "rm -fr * in /" and didn't get their POSIX
> mandated behavior, would curse you?
>
> You are playing Mommy, to people and not allowing them to do what
> they are asking the computer to do.
>
> [... and ~40 lines re. Jim, GNU, POSIX, the universe ...]
Dear Linda,
why don't you stick to the point?
You provided a patch which changes the *default behaviour* of rm,
and Jim told you that we can't/shouldn't do this.
What you want was an option to delete the content of a directory.
So why discussing all the world and his brother instead of providing
a new patch introducing such a new option (e.g. --only-dir-content,
there should be a better name)?
Generalizations like that don't help here, IMHO.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 11:17:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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, maybe relegate the undesirable required behavior to when
POSIXLY_CORRECT is set, or even simply ignore it. In fact, over the
years, I have deliberately made a few GNU tools contravene some aspects
of POSIX-specified behavior that I felt were counterproductive.
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 all other vendor-supplied rm programs)
without a very good reason.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 16:43:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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, when
> that fails, maybe relegate the undesirable required behavior to when
> POSIXLY_CORRECT is set, or even simply ignore it. In fact, over the
> years, I have deliberately made a few GNU tools contravene some aspects
> of POSIX-specified behavior that I felt were counterproductive.
>
> 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 all other vendor-supplied rm programs)
> without a very good reason.
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.
This isn't a feature that could be working in a script for someone.
It isn't something that was recently removed that would cause a script
to break. A script will run now with the same behavior across
multiple different types of systems. I think we should leave things
unchanged.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 06 Sep 2012 17:41:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 12339 <at> debbugs.gnu.org (full text, mbox):
Bernhard Voelker wrote:
>
>
> On September 6, 2012 at 12:56 PM Linda Walsh <coreutils <at> 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 would curse us
>>> for making GNU rm remove their precious files when they accidentally ran
>>> that command.
>> ---
>>
>> Just like people who ran "rm -fr * in /" and didn't get their POSIX
>> mandated behavior, would curse you?
>>
>> You are playing Mommy, to people and not allowing them to do what
>> they are asking the computer to do.
>>
>> [... and ~40 lines re. Jim, GNU, POSIX, the universe ...]
>
> Dear Linda,
>
> why don't you stick to the point?
----
I wasn't the one who raised the point of people
cursing Gnu for removing their precious when they accidently or deliberately
tried to invoked rm in a way to generate a non-functional behavior.
If we were going to talk about them cursing gnu, I thought
I would fully put it in perspective.
That's what that exposé was about.
Note -- that it wasn't personally directly, and included listed
facts for a stronger counterpoint to what, admittedly, was likely a lightly
given reason for not changing a default behavior. It was addressing
that comment, alone.
You want an on-point counter proposal:
Might I suggest this as a rational counter proposal.
If the user issues rm -r ., it issues a warning:
"Do you really wish to remove all files under '.'"?
That won't break compatible behavior. Only if the user chooses
the non-default 'force' option "do what I say and shut up", which is not
a default option", would it do the action I suggest.
In any case, if POSIX_CORRECTLY is set, it will act as per POSIX requirements.
It is TELLING, and important to understand Jim's statement
" Very few people ever set that envvar." Most people don't want strict POSIX
compatbility -- for reasons exactly like this -- the POSIX isn't about
usability, it's
about program portability. So for interactive use, it wouldn't be something most
people would want to use.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 14:18:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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, when
> that fails, maybe relegate the undesirable required behavior to when
> POSIXLY_CORRECT is set, or even simply ignore it. In fact, over the
> years, I have deliberately made a few GNU tools contravene some aspects
> of POSIX-specified behavior that I felt were counterproductive.
>
> 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 all other vendor-supplied rm programs)
> without a very good reason.
----
So if I make it enabled with an ENV var set to RM_FILES_DEPTH_FIRST, to enable
the behavior, then you'd have no problem accepting the patch?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 14:24:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 all other vendor-supplied rm programs)
>> without a very good reason.
>
> ----
> So if I make it enabled with an ENV var set to RM_FILES_DEPTH_FIRST,
> to enable
> the behavior, then you'd have no problem accepting the patch?
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. But
if you want to submit a patch so that 'rm -r --depth-first .' does what
you want, I'm probably 60-40 in favor of including it.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 14:32:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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. But
> if you want to submit a patch so that 'rm -r --depth-first .' does what
> you want, I'm probably 60-40 in favor of including it.
---
I wouldn't be opposed to adding it in addition, but I don't want the extra
typing for what is the more common case for me, but given that the current
behavior is to return an error -- and there is an expectation of being able to type
in non-working commands just to see the error message -- imagine their surprise
and how they would curse if you added an option that actually made that previously
illegal action, work.
Most of them who type in random wrong commands just to see error messages aren't
smart enough to use environment variables.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 14:47:03 GMT)
Full text and
rfc822 format available.
Message #167 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 for me,
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 _on your system_ to avoid extra typing on your
part.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 14:56:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 now, the feature is unused, So hurting compatibility
is not an issue - users can push for the feature on other systems as needed.
It certainly isnt' a safety issue, since
rm **
on a bouncy keyboard is alot easier to type than rm -fr *,
and the former will remove all files under the current dir
(just none of the directories)
I suppose rm **;rmdir ** would work -- but but require SHELL.
I think adding the case of rm -fr . or (dirname/.) to delete contents
of the dir, but not the dir itself makes more sense and is safer than
the easier to type rm **
>
> This isn't a feature that could be working in a script for someone.
> It isn't something that was recently removed that would cause a script
> to break. A script will run now with the same behavior across
> multiple different types of systems. I think we should leave things
> unchanged.
----
It's only been recently that I've noticed rm -fr . not working and
I can't figure out why since it hasn't been around for so long.
Consider the parallel, if I want to make sure I copy the contents
of a dir, I need to use cp dir/. dest/
If I use dir/ or dir, they both end up in dest (even with the "/").
That means without using ".", the contents are not addressable, so what is
demanded by 'cp', is refused by 'rm'.
That is not a consistent user interface and is symptomatic of poor design.
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 the current dir before anything else -- as it goes completely
contrary to how rm has to work.
I say it's a design flaw and inconsistent with other programs.
But if I can set an env var and have it work on my system, someone else
can work to get the core utils to work consistently...
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 15:04:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 _on your system_ to avoid extra typing on your
> part.
---
Doesn't work for programs that need to call rm to remove all files
in a dir.
And I already have changed default behavior on MY systems.
I already added the patch below -- that only does my behavior if the
user isn't running in POSIXLY_CORRECT mode.
Now it's certainly easier to set an env var 1 place to control script
behavior than making changes in all the places...
I'm just trying to get the env var in so I don't have to distribute
a version of rm with my scripts that works.
-----
--- src/remove.c 2011-10-10 00:56:46.000000000 -0700
+++ src/remove.c.new 2012-09-06 14:28:07.816810683 -0700
@@ -173,6 +173,35 @@
}
}
+
+/* separate functions to check for next part of file name being dotdot or...*/
+
+static inline bool
+dotdot (char const *file_name)
+{
+ if (file_name[0] == '.' && file_name[1])
+ {
+ char sep = file_name[(file_name[1] == '.') + 1];
+ return (! sep || ISSLASH (sep));
+ }
+ else
+ return false;
+}
+
+/* dot */
+
+static inline bool
+dot (char const * file_name)
+{
+ if (file_name[0] == '.')
+ {
+ char sep = file_name[1];
+ return (! sep || ISSLASH(sep));
+ }
+ else
+ return false;
+}
+
/* Prompt whether to remove FILENAME (ent->, if required via a combination of
the options specified by X and/or file attributes. If the file may
be removed, return RM_OK. If the user declines to remove the file,
@@ -203,6 +232,7 @@
int dirent_type = is_dir ? DT_DIR : DT_UNKNOWN;
int write_protected = 0;
+ int special_delete_content = 0;
/* When nonzero, this indicates that we failed to remove a child entry,
either because the user declined an interactive prompt, or due to
@@ -222,7 +252,11 @@
wp_errno = errno;
}
- if (write_protected || x->interactive == RMI_ALWAYS)
+ if (!x->posix_correctly && dot(filename) && !x->force)
+ special_delete_content = 1;
+
+
+ if (write_protected || x->interactive == RMI_ALWAYS || special_delete_content)
{
if (0 <= write_protected && dirent_type == DT_UNKNOWN)
{
@@ -281,11 +315,16 @@
if (dirent_type == DT_DIR
&& mode == PA_DESCEND_INTO_DIR
&& !is_empty)
- fprintf (stderr,
- (write_protected
- ? _("%s: descend into write-protected directory %s? ")
- : _("%s: descend into directory %s? ")),
- program_name, quoted_name);
+ {
+ char * action = special_delete_content
+ ?
_("delete contents of")
+ :
_("descend into");
+ fprintf (stderr,
+
(write_protected
+ ?
_("%s: %s write-protected directory %s? ")
+ :
_("%s: %s directory %s? ")),
+ action,
program_name, quoted_name);
+ }
else
{
if (cache_fstatat (fd_cwd, filename, sbuf, AT_SYMLINK_NOFOLLOW) != 0)
@@ -476,7 +515,8 @@
/* If the basename of a command line argument is "." or "..",
diagnose it and do nothing more with that argument. */
- if (dot_or_dotdot (last_component (ent->fts_accpath)))
+ if ( (x->posix_correctly ? dot_or_dotdot : dotdot)
+ (last_component
(ent->fts_accpath)))
{
error (0, 0, _("cannot remove directory: %s"),
quote (ent->fts_path));
--- src/remove.h 2011-07-28 03:38:27.000000000 -0700
+++ src/remove.h 2012-09-06 13:33:01.282362765 -0700
@@ -34,6 +34,14 @@
/* If true, ignore nonexistent files. */
bool ignore_missing_files;
+ /* true if force (-f) was specified indicating user knows what they
+ * are doing and don't want to questioned or see errors from command */
+ bool force;
+
+ /* true for users wanting strict posix compliance of more flexible, lax,
+ * or useful behaviors */
+ bool posix_correctly;
+
/* If true, query the user about whether to remove each file. */
enum rm_interactive interactive;
--- src/rm.c 2011-10-02 02:20:54.000000000 -0700
+++ src/rm.c 2012-09-06 13:33:04.132500554 -0700
@@ -206,6 +206,7 @@
bool preserve_root = true;
struct rm_options x;
bool prompt_once = false;
+ x.posix_correctly = (getenv ("POSIXLY_CORRECT") != NULL );
int c;
initialize_main (&argc, &argv);
@@ -222,10 +226,11 @@
{
switch (c)
{
- case 'f':
+ case 'f': /* suppress warnings/errors */
x.interactive = RMI_NEVER;
x.ignore_missing_files = true;
prompt_once = false;
+ x.force = true;
break;
case 'i':
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 16:31:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 the current dir before anything else -- as it goes
> completely
> contrary to how rm has to work.
At the syscall level, unlink(".") is required to fail. To remove a
directory, you must remove its proper name. You can use
unlink("../child") on systems like Linux that let you remove a directory
that is used as a process' current working directory (on systems like
Windows where this action is forbidden, there's no way to remove the
current working directory). Therefore, at the shell level, POSIX will
let you do 'rm -r ../child'. If you think that POSIX should _also_ let
you attempt 'rm -r .', then propose that as a defect report against
POSIX, rather than griping here.
>
> I say it's a design flaw and inconsistent with other programs.
I would say that it is not a design flaw, but that it is consistent with
the fact that the unlink(".") syscall is required to fail, and that it
is consistent with other Unix implementations. We can agree to disagree
on that point.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 20:57:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 it would try the current dir before anything else -- as it goes
>> completely
>> contrary to how rm has to work.
>
> At the syscall level, unlink(".") is required to fail. To remove a
> directory, you must remove its proper name. You can use
> unlink("../child") on systems like Linux that let you remove a directory
> that is used as a process' current working directory (on systems like
> Windows where this action is forbidden, there's no way to remove the
> current working directory). Therefore, at the shell level, POSIX will
> let you do 'rm -r ../child'. If you think that POSIX should _also_ let
> you attempt 'rm -r .', then propose that as a defect report against
> POSIX, rather than griping here.
>
>> I say it's a design flaw and inconsistent with other programs.
>
> I would say that it is not a design flaw, but that it is consistent with
> the fact that the unlink(".") syscall is required to fail, and that it
> is consistent with other Unix implementations. We can agree to disagree
> on that point.
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 directory, and,
thus, "rm" _MUST_ do a depth first traversal. If it did and gave an error
at the end: no issue.
It's the special check BEFORE doing the work it would normally do, and failing
BEFORE, it does it's NORMAL work -- the depth first deletion, that I am against.
Griping against POSIX is like griping against the government. But very
few people always go the speed limit and would regard a vehicle that is
*unable* function normally, as faulty.
So I am not disagreeing that it should fail, Please be clear about what I
am asking. Also, I would *expect*, that rm -r . would at least, _ask_ you
if you wanted to remove files under a directory that will be unable to be deleted.
I am only asking for the behavior I describe to work without issuing an error
when I do "rm -fr" I am specifically asking rm to forcefully remove what it
can and remove and CONTINUE to delete what it can in spite of any errors it might
encounter. Again, the fact that this fails defies normal logic with 'rm'. I don't
believe that rm -fr . has failed for 20 years. I don't know when it changed,
but it used
to be that "rm" didn't have a special check for "." -- BECAUSE -- as you
mention, an attempt
to unlink "." will fail -- Using the "-f" suppresses any error message.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 21:21:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 directory, and,
> thus, "rm" _MUST_ do a depth first traversal. If it did and gave an error
> at the end: no issue.
Indeed, reading the original V7 source code from 1979:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/rm.c
while(--argc > 0) {
if(!strcmp(*++argv, "..")) {
fprintf(stderr, "rm: cannot remove `..'\n");
continue;
}
rm(*argv, fflg, rflg, iflg, 0);
}
shows that _only_ ".." was special, "." was attempted in-place and
didn't fail until the unlink(".") after the directory itself had been
emptied. It wasn't until later versions of code that "." also became
special.
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 not require, early failure. However, I just checked, and the
prohibition for an early exit on "." has been around since at least
POSIX 2001, so you are now coming into the game at least 11 years late.
So, until you take it up with the POSIX folks, I don't think anyone on
the coreutils side cares enough to bother changing the default behavior,
now that it has been standardized, and even though the standardized
behavior is tighter than the original pre-standard behavior.
> Griping against POSIX is like griping against the government.
No, I actually find the Austin Group quite reasonable to work with,
especially if you can provide backup evidence like the V7 source snippet
I just mentioned.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 21:32:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 not require, early failure. However, I just checked, and the
> prohibition for an early exit on "." has been around since at least
> POSIX 2001, so you are now coming into the game at least 11 years late.
----
Those changes only started hitting the field a few years ago.
Bash just started working to adopted the 2003 standard with
it's 4.0 version -- before that it was 1999 -- I didn't even know
there was a 2001....
Except that trying to get them to change things now, I'd encounter
the same arguments I get here -- that users expect to be able have "-f"
not really mean force -- and to report errors on ".".
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 were proposing to ban "space"
(as well as 0x01-0x1f) in file names). Attempting to deal with people
who want to turn POSIX into a restriction document -- not a standard
reflecting current implementations, is well beyond my social abilities.
I can't even get engineers -- when faced with clear evidence
of programs that put out inconsistent output to fix them. They know it's
bad output -- and even warn that they are about to do the wrong thing
in warnings. Somehow this is considered preferable to doing something
useful.
So expecting a group that is heavily into bureaucracy to listen to
reason just doesn't seem like a reasonable expectation.
I did go to their website though and see what they were discussing,
and when I saw that sentiment was going in favor of limiting allowed characters
in filenames, I was to ill to stay.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 22:10:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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. It wasn't until later versions of code that "." also became
> special.
I also decided to look around there, and found some of the turning points:
Up to 4.2BSD, the V7 behavior was kept.
(http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/bin/rm.c)
rm -rf . was forbidden in 4.3BSD (26 years ago).
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/bin/rm.c
The removal of dir/. (and dir/..) was not forbidden until Reno.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/bin/rm/rm.c
cp = rindex(arg, '/');
if (cp == NULL)
cp = arg;
else
++cp;
if (isdot(cp)) {
fprintf(stderr, "rm: cannot remove `.' or `..'\n");
return (0);
}
Maybe the classical behavior stuck around longer in the more SysV-ish Unices.
The Ultrix-11 3.1 tree on TUHS from 1988 has a rm that looks very much like
V7, but I can't find anything to compare it to until OpenSolaris.
Did POSIX force BSD to change their rm in 1988? I think it's more likely that
POSIX simply documents a restriction that BSD had already added. Either way
the latest POSIX revisions certainly can't be blamed.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 22:52:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 were proposing to ban "space"
> (as well as 0x01-0x1f) in file names).
You aren't looking very hard, then. The proposal currently being
considered by the Austin Group is a ban on newline (and newline only)
from file names, because that is the one and only character whose
presence in file names causes ambiguous output for line-oriented tools.
Forbidding space and most non-printing control characters was rejected
as impractical. And even with the proposed ban on newline, it is still
just that - a proposal, and not a hard rule, waiting for implementation
practice to see if it is even doable.
http://www.austingroupbugs.net/view.php?id=251
Read the whole thing. The original poster mentioned a much tighter
bound, but it was shot down, with the _only_ thing being left on the
table under current discussion is _just_ the limitation of newline.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 23:26:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 been
> emptied. It wasn't until later versions of code that "." also became
> special.
>
> 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 not require, early failure. However, I just checked, and the
> prohibition for an early exit on "." has been around since at least
> POSIX 2001, so you are now coming into the game at least 11 years late.
In addition to Alan's argument that 4.3BSD forbade '.' before POSIX
began (and therefore the POSIX folks DID standardize existing practice,
even it wasn't universally common at the time), I find this statement
from POSIX quite informative (line 104265 in POSIX 2008), on why any
proposal to allow 'rm -rf .' to remove non-dot files will probably be
denied:
>> 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 .*
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 07 Sep 2012 23:41:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 it would show up first in such
a situation.
As stated before, I am more interested in the "-f"=force it anyway option,
that says to let it fail, and continue, ignoring failure.
I think that may be where the problem has been introduced.
I never used rm - .
Certainly rm ** is easier to mistype than rm -r .* so by that logic, that
should be disallowed as well?
I submit it is the behavior of "-f" that has changed -- and that it
used to mean "force" -- continue in spite of errors, and it is
that behavior that has changed, as I would would always have expected
rm -r . to at least return some error I didn't care about -- What I
wanted was the depth-first removal, and -f to force it to continue despite
errors.
How long has -f NOT meant "--force" -- as now it only overlooks write
protection errors which sounds very weak.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 00:02:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/07/2012 09:02 AM, Linda Walsh wrote:
>
> --- src/remove.c 2011-10-10 00:56:46.000000000 -0700
> +++ src/remove.c.new 2012-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
documentation. Also, you do not have copyright assignment on file with
the FSF (but if you'd like to pursue this patch further, we can help you
complete the copyright assignment paperwork). Therefore, this patch
cannot be taken as-is.
> @@ -203,6 +232,7 @@
>
> int dirent_type = is_dir ? DT_DIR : DT_UNKNOWN;
> int write_protected = 0;
> + int special_delete_content = 0;
Furthermore, your indentation appears hideous in this email; I'm not
sure you created the patch, and whether this is an artifact of your
mailer corrupting things or whether you really did disregard existing
indentation, but you'd have to clean that up before your patch can be
anywhere worth including.
> + char * action =
> special_delete_content
> +
> ? _("delete contents of")
> +
> : _("descend into");
> + fprintf (stderr,
> + (write_protected
> +
> ? _("%s: %s write-protected directory %s? ")
> +
> : _("%s: %s directory %s? ")),
This is a translation no-no (not to mention that your hideous
indentation made it hard to read because it was so much longer than 80
columns). Please don't split English sentences across two separate _()
calls that are then pasted together, but rather write two _() calls of
the two complete sentences.
> +++ src/rm.c 2012-09-06 13:33:04.132500554 -0700
> @@ -206,6 +206,7 @@
> bool preserve_root = true;
> struct rm_options x;
> bool prompt_once = false;
> + x.posix_correctly = (getenv ("POSIXLY_CORRECT") != NULL );
Elsewhere in coreutils, we name such a variable posixly_correct, not
posix_correctly.
And finally, remember my advice - if you want this mode, add it as a new
long option, and NOT as an abuse of POSIXLY_CORRECT, if you want to
avoid controversy and even stand a chance of getting it approved for
inclusion.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 00:04:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 no way to specify, using "rm" to delete the contents
of a directory but not the directory itself.
I just want to "clean" out a directory -- I don't want to try to delete the
directory itself. 4.3BSD is breaking the intended functionality of
a depth first *requirement* for rm to remove a dir. It's well known
that the contents must be removed before ".", so trying to remove "." should
only fail after the depth first traversal -- that would be expected behavior.
I'm NOT trying to remove "." I'm using it to indicated that I only want the
contents of the directory deleted. It's like using "/" with a symlink to get at
the dir, except that doesn't work reliably -- the only thing that works reliably
to get at the contents is "."
Try <cp|mv> -r dir1/ dir2/ -- they'll move dir1 under dir2, the same as without
the "-r". The only way for "-r" to address content is by using "." as the source,
in
cp -a src/. dst[/]
Note cp -a src/. dst/. works, but try to "mv", and you get the type of error you'd
expect from trying to "destroy" "b/."
Note the copy works but not the mv. cp should realize it is writing "." to "."
which
is illegal -- but it allows it because it knows what the user *wants* to do.
'mv', is stricter -- as you want to move one inode over the top of another.
As a "source address, "." is allowed to mean content, but as a destination, it isn't
allowed as a writeable destination.
That's the problem with "rm", when uing rm -r '.' that specifies the start of a
recursive operation where writes will begin, depth first. It's not until the
very end that it tries to do the illegal "write (delete)" operation to ".".
If 'cp' allows "." as a source, (and even accommodates it as a target for "cp",
so should 'rm' allow "." to mean the start of a deletion, but NOT the dir itself.
That's the interpretation that cp is using -- as if it was trying to cp the dir
itself
over the top of the target, it would give an error message, but it doesn't.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 00:20:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 willing to admit
some reasonability in the objection) to changing the default behavior.
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.
Vs. the option of adding it as a long option -- that's pushing it
too far -- and doesn't work for me. as it's easier for me to maintain
and distribute a patch to rm or my own version than it is to have it
as a long option. Reason: doing it in rm OR as an ENV var does it
in one place and all my code/interactivity benefits . Doing it in
a long option -- must be paid for on each use. The cost doesn't
work for me nor would it work for anyone considering cost v. benefit.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 00:25:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 already told it to you:
rm -rf * .[!.] .??*
>
> I just want to "clean" out a directory -- I don't want to try to delete the
> directory itself.
Then use the triple-glob. This is portable to both POSIX and to the old
implementations we have been discussing.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 01:26:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 there is, and Paul already told it to you:
>
> rm -rf * .[!.] .??*
----
You must have missed that rm doesn't expand shell globs... and I don't
want to get the shell involved for rm'ing files anymore than cp needs
to to copy directories or the files in a dir and not the dir.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 02:30:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 03:07:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 .. or it can fail at
the beginning, as long as the -f option said to ignore errors
and keep going.
I don't want a wildcard solution. It's a wildcard. (Doh!)
The issue was changing the default no?
You don't think I'm being reasonable by agreeing and saying
a non default environment var?
Why should cp accept "." as "addressing the contents of
a directory, but "rm" be deliberately crippled? We've
excluded safety, since no one will get to the option unless
they've enabled it and unless they choose force, since the
they should get a prompt asking if they want to delete the
delete the files in protected directory ".", right?
So far no one has addressed when the change in "-f' went in
NOT to ignore the non-deletable dir "." and continue recursive delete,
as normal behavior would have it do. Posix claims the rational is to
prevent accidental deletion of all cur-dir when using rm -r ., however
if it is queried in that case, and noting that rm ** is just as dangerous,
but not as clean as it 'only' deletes all files, and leaves the dir skeleton.
So posix's rationals wouldn't seem to be 1) that important, and 2) would be
addressed by sticking with the current behavior or prompting first -- which would
make more sense rather than arbitrarily deciding for them and removing
the ability for rm to remove just files -- by itself. with no other utilities
invoked.
Why shouldn't rm have the ability to only target everything under a specified
point,
rather than always including the point?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 03:35:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 think the
change you're referring to is a change at all. -f never had the effect you
think it should have.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 04:09:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 removal of "." so I don't think the
> change you're referring to is a change at all. -f never had the effect you
> think it should have.
>
If I was using BSD, I would agree.
---
But most of my usage has been on SysV compats Solaris, SGI, Linux, a short
while on SunOS back in the late 80's, but that would have been before it
changed anyway.
For all i know it could have been a vendor addin, but that's
not the whole point here.
Do you want to support making "." illegal for all
gnu utils for addressing content?
If not, then we should look at making a decision that it can
be used to address content and ensure the interface is consistent
going forward.
I think you'll find many more people against the idea and wondering
why it's in 'rm' and why "-f" doesn't really mean ignore all the errors
it can and why that one should be specially treated. Of course they also might
wonder why rm doesn't follow the necessary algorithm for deleting files --
and delete contents before dying issuing an error for being unable to delete
a parent. Which might also raise why -f shouldn't be usable to silence permission
or access errors as it was designed to.
There are plenty of good reasons aside from BSD historic usage why it should
be designed in, especially when it's being tucked away as a non-default behavior
that would need environmental triggering to even be available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 04:43:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 was a nice trip down memory lane!
I've *used* all those 'rm' implementations. I'm even old
enough to remember when 'rm' automatically refused to
remove itself.
> You don't think I'm being reasonable by agreeing and saying
> a non default environment var?
No, because then currently-working scripts might have
to be changed to guard against that variable being set.
Clearly you don't agree with the POSIX rationale.
Reasonable people can disagree, and then move on.
The nice thing about free software is that you can
build your system the way you like. You don't have
to convert the rest of us.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 04:58:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 consulted before rejecting removal of "." so I don't think the
> > change you're referring to is a change at all. -f never had the effect you
> > think it should have.
> >
> If I was using BSD, I would agree.
> ---
> But most of my usage has been on SysV compats Solaris, SGI, Linux, a short
> while on SunOS back in the late 80's, but that would have been before it
> changed anyway.
SGI is dead, Sun is dead, the game's over, we're the winners, and our rm has
been this way forever.
>
> For all i know it could have been a vendor addin, but that's
> not the whole point here.
>
> Do you want to support making "." illegal for all
> gnu utils for addressing content?
I don't think "addressing content" is a clearly defined operation, no matter
how many times you repeat it.
Consistency between tools is a good thing, but consistency between OSes is
also good, and we'd be losing that if any change was made to GNU rm's default
behavior. Even OpenSolaris has the restriction: see lines 160-170 of
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rm/rm.c
>
> I think you'll find many more people against the idea and wondering
> why it's in 'rm' and why "-f" doesn't really mean ignore all the errors
> it can and why that one should be specially treated. Of course they also might
> wonder why rm doesn't follow the necessary algorithm for deleting files --
> and delete contents before dying issuing an error for being unable to delete
> a parent. Which might also raise why -f shouldn't be usable to silence permission
> or access errors as it was designed to.
Look, I agree isn't not logical or elegant. But we have a standard that all
current Unices are obeying, and logic and elegance alone aren't enough to
justify changing that.
A new option that you can put in an alias is really the most realistic goal.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 07:10:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 environment
variable. I explained a similar refusal for sort.c just two weeks ago:
https://lists.gnu.org/archive/html/coreutils/2012-08/msg00172.html
> ... we have a strong aversion to adding
> support for new environment variables in coreutils programs
> because it makes formerly-robust usage prone to malfunction or abuse.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Sat, 08 Sep 2012 19:22:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 12339 <at> debbugs.gnu.org (full text, mbox):
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 think "addressing content" is a clearly defined operation, no matter
> how many times you repeat it.
---
Until you are able to understand content addressability, you won't
understand the importance or need for doing so. Without targeted addressing
all you have a blunt intstruments, you might as well go back to bear skins
and stone knives to match the 'we must conquer' mentality, that is it's evolutionary
equal.
> Consistency between tools is a good thing, but consistency between OSes is
> also good, and we'd be losing that if any change was made to GNU rm's default
> behavior. Even OpenSolaris has the restriction: see lines 160-170 of
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rm/rm.c
----
Rationalizations to avoid coming to a something that works for everyone.
> A new option that you can put in an alias is really the most realistic goal.
---
Aliases don't work when you issue 'exec'. They aren't able to be
exported or inherited by subsequent processes -- something I have asked for
multiple times, for exactly this type of issue. As it is, you suggest a
cripple solution to deal with crippled functionality.
You and others are demonstrating the current level of ability they
possess in order to solve problems, and the overriding priority of corporate
compliance. Diversity is an anathema to your thinking. In the end
result of control - Gnu seems little different from those the rally against.
It is only their methods that differ, but they both equally end up mandating
their solutions through the means they have. Is Gnu's distribution process
open or closed source? And by open -- it includes all the software and codes
necessary to make changes to the distribution. I would think that unlikely.
This is not an isolated incident. It may not be tied solely to
gender, but I have had other women comment on similar experiences in the
male-owned software industry. You are only demonstrating what good
soldiers you are in the service of your masters.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Wed, 12 Sep 2012 22:53:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I hope to prove the subject convincingly in the following sections, If
you can, reading this in the original HTML might be useful, as I don't
know it will end up when converted to text. I tried to format it for
readability .. so if the text format isn't...(still tried to limit
margins and use monospace font)... Writing this to appeal to those with
an open mind
is the best I can hope for.
I. In regards to /*Compatibility with Default Behavior*/. If there is a
change to a function or functionality that people use, then you have
broken compatibility with past functionality. If it was something that
generated an error in the past, fixing it doesn't break compatibility
with past function. Example:
> mkdir aaa
> ln -s aaa bbb
> rm -r bbb ## deletes symlink 'recursively' leaving
## aaa untouched.
> ln -s aaa bbb
> rm -r bbb/ ## this would make it clear that we
## are addressing a dir that bbb is
## pointing to; however...
rm: cannot remove directory `bbb': Not a directory.
## rm is confused, as ls shows:
> 'ls' -gGld bbb/
drwxrwxr-x 2 6 2012-09-11 09:48 bbb/
Rumor has it 'rm' may now include a fix for this so that it knows that
"/" means '/address/ the directory at the end of this symlink'.
Did this change default behavior? Yes. Did it change default
functional behavior? No. Before, "rm -r bbb/" was not valid syntax --
and wasn't part of "default behavior". A new feature was created where
before there was none.
Implementing functionality where before there was none, is not normally
considered "changing default behavior", as there was no legal or
functional prior behavior that someone would have been _relying_ on.
To someone unfamiliar with "/" being the directory separator, you could
just as easily have added a "/" flag that when appended to a word, tells
rm to treat it as a directory.
II. Basenames vs. dirnames. What are they? Basenames are the final
part of a name that has been chosen to name the entry located in "some
dir". Let's look at some different "Cases" of sample pathnames (skipping
the easy ones, given the audience):
Case A: "/" What is the dirname and what is the basename?
Answer: <null> and <null>.
That's why it is called the root -- it doesn't have a name entry
somewhere as it is the top of the tree -- there is nothing above it to
hold a name for it. It has to exist on every system, so by convention,
it is called the 'root' directory.
Case B: "ENTRY/" What is the dirname and what is the basename?
Answer: Dirname="ENTRY", basename=<null>. (Explanation seems unnecessary).
Case C: "ENTRY" Dir and Basenames?
Answer: it depends on context and what it really is.
Whether or not 'ENTRY' is a basename or a dirname depends on whether or
not 'ENTRY' is a directory.
Example. In it's default mode rm removes only files. I.e.
"rm a b c ENTRY d" -- rm expects all entries to to simple basenames. If
it encounters a dirname, it issues an error and refuses to operate on it.
In it's recursive mode, rm will accept basenames and dirnames. It will
inspect each entry to determine if it is a file (basename) or a
dir(dirname).
As POSIX states:
If, on the other hand, you specify the "-r" switch to rm, it enables it
to remove directories, but it doesn't treat them the same as other files
(because they still are not 'basenames' - they are directories). So
the first difference that might be noted, is that rm begins a depth
first traversal on the contents of that directory. Once it is empty an
is no longer containing any non-structural entries, it will then enable
it to be deleted using rmdir (that handles deconstructing internal
structural components that unlink wouldn't handle).
Only after the contents have been removed is it no longer a dirpath --
and it becomes the next active "operand" of the "rm" verb/action.
At that point, it either deletes it or not, depending on what is
permitted by policy (usually security settings).
There are 2 entries not covered usually covered by security policies, as
they are not discretionary entries -- they are mandatory components of
the OS, namely "." and "..". If "rm" encounters one of those at the
point such an entry becomes the "entry to be operated on" (the operand),
POSIX directs that rm shouldn't even try to delete those entries (as on
some systems this might succeed, if the underlying OS allows it, so in
order to provide portable behavior, a compliant "rm" will not attempt to
delete those entries.
POSIX states:
If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component), rm
shall write a diagnostic message to standard error and do nothing
more with such operands.
However, "rm" if it encounters "." or ".." and the user has specified
that they are to be treated as files (i.e. they do no specify -r), "rm"
already refuses to delete those entries as they are not normal files or
basename components -- but are structural components to facilitate
addressing -- specifically ".." allows addressing the directory above
the current dir, while "." allows one to specify an explicit starting
point for an operation as the root of the current directory.
The wording for treatment of "." and ".." is consistent for the case
that they are being addressed as "targets" not being used as addresses.
POSIX states for directories, with (recursion),
For each entry contained in /file/, other than dot or dot-dot,
the four steps listed here (1 to 4) shall be taken with the
entry as if it were a /file/ operand. The /rm/ utility shall not
traverse directories by following symbolic links into other
parts of the hierarchy, but shall remove the links themselves.
The first thing it does when operating on a directory is to enter the
directory and remove associated files. Only when a directory is empty,
is it able to be addressed as a file-type operand of the parent that
can be removed with 1 operation (rmdir vs. unlink). If, however, you remove
the contents, and now when you back up you have been removing contents under
".", then -- discovering "." as an operand, "it should issue an error
and have nothing more to do with that file". This is entirely
consistent with
the wording in POSIX. It would also be the case if "-f" had been specified,
that any diagnostic would be suppressed.
As POSIX is a computer portability standard, one would imagine that they
know the difference between dirnames and basenames and that a dirname
can only be treated as a basename when it has been emptied of files.
Gnu's version of rm worked as I described prior to version 6. Version 5
in openSuse 10.1 and earlier was only *retired about 4 years ago* -- not
"23 years ago" like some people would make up. This is a relatively
new change
that is causing problems and I would like to see it reverted to the letter
of computer science practice -- as it would still adhere to the letter
of POSIX's requirements.
III) Please note, that just as in section I, we are [re]adding
functionality where before there was none. Thus this is no more a
compatibility feature than adding any other "new feature", as before,
only "dysfunction" existed. Adding new features in the place of a void
is not something that can break previous compatibility, as it makes no
sense to have dependencies on a void...
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 13 Sep 2012 00:30:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/12/2012 04:51 PM, Linda Walsh wrote:
> I hope to prove the subject convincingly in the following sections, If
> you can, reading this in the original HTML might be useful, as I don't
> know it will end up when converted to text.
HTML mail is forbidden on this list; the mail engine stripped it to
plain text before it ever hit the list or the online bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12339#239
> I tried to format it for
> readability .. so if the text format isn't...(still tried to limit
> margins and use monospace font)...
So please bear with me if my inability to see your intended markup means
that I misinterpret your intent.
> Before, "rm -r bbb/" was not valid syntax --
Sorry, but 'rm -r bbb/' has ALWAYS been valid syntax in POSIX, and has
always meant 'remove the directory found by resolving 'bbb', even if
'bbb' is a symlink to a directory. The fact that the Linux kernel
rmdir("bbb/") has not always followed POSIX in this regards makes it
harder to use as a use case - because then we are torn with whether to
honor the kernel decision of how it should behave or whether to pay the
penalty of a slower wrapper function that does it the way POSIX says it
should behave. The best we can do is document which way we have chosen
to go.
> II. Basenames vs. dirnames. What are they? Basenames are the final
> part of a name that has been chosen to name the entry located in "some
> dir".
They are also well-defined terms in the POSIX standard.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_40
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
Let's look at some different "Cases" of sample pathnames (skipping
> the easy ones, given the audience):
>
> Case A: "/" What is the dirname and what is the basename?
>
> Answer: <null> and <null>.
Unfortunately, your interpretation is not consistent with the POSIX
definitions. The POSIX-mandated answer is a dirname of '/' and a
basename of '/'. Additionally, this particular file name is always a
directory.
> Case B: "ENTRY/" What is the dirname and what is the basename?
>
> Answer: Dirname="ENTRY", basename=<null>. (Explanation seems unnecessary).
Unfortunately, your interpretation is not consistent with the POSIX
definitions. The POSIX-mandated answer is a dirname of '.' and a
basename of 'ENTRY'. Additionally, this particular file name must
always resolve to a directory (that is, either 'ENTRY' is a directory,
or 'ENTRY' is a symlink whose eventual target is a directory).
> Case C: "ENTRY" Dir and Basenames?
>
> Answer: it depends on context and what it really is.
Unfortunately, your interpretation is not consistent with the POSIX
definitions. The POSIX-mandated answer is a dirname of '.' and a
basename of 'ENTRY'. But you are correct that it may or may not be a
directory.
>
> Whether or not 'ENTRY' is a basename or a dirname depends on whether or
> not 'ENTRY' is a directory.
Rather, the POSIX definition states that 'ENTRY' is a basename because
it is the last non-slash component of the overall string, after
stripping any trailing slashes. Remember, a directory is ALSO a file,
just like a symlink or a socket or a character device is also a file.
The term basename applies to any file, not just non-directory files.
>
> Example. In it's default mode rm removes only files.
Correction - in its default mode, rm removes regular files, symlinks,
fifos, block devices, character devices, socket files, and any other
implementation extension file types, but has special case treatment of
directory files. This special case treatment is mandated by POSIX, to
match historical practice.
> "rm a b c ENTRY d" -- rm expects all entries to to simple basenames. If
> it encounters a dirname, it issues an error and refuses to operate on it.
Correcting your terminology:
If it encounters a *directory*, it issues an error and refuses to
operate on it.
Remember, _every single file name_ has both a dirname and a basename,
even if the dirname is the implied '.', so all five of the arguments in
your examples include a basename as part of the name. But that does not
tell us whether the file is a directory, a regular file, or some other
type of file.
>
> In it's recursive mode, rm will accept basenames and dirnames. It will
> inspect each entry to determine if it is a file (basename) or a
> dir(dirname).
Again correcting your terminology:
rm will accept directories in addition to other file types.
> As POSIX states:
>
> If, on the other hand, you specify the "-r" switch to rm, it enables it
> to remove directories, but it doesn't treat them the same as other files
> (because they still are not 'basenames' - they are directories).
Wrong terminology, but you are correct that directories are handled
differently; but that's because unlink() and rmdir() are different
functions and so directories MUST be handled differently.
> Only after the contents have been removed is it no longer a dirpath --
This statement makes no sense in light of POSIX terminology. Maybe you
meant:
Only after the contents have been removed is it an empty directory that
can be acted on by rmdir().
> There are 2 entries not covered usually covered by security policies, as
> they are not discretionary entries -- they are mandatory components of
> the OS, namely "." and "..".
Actually, believe it or not, '.' and '..' are NOT mandatory directory
entries in POSIX. It is mandatory that they be handled in file name
resolution, but it is possible to have a file system where readdir()
never returns '.' or '..'.
> As POSIX is a computer portability standard, one would imagine that they
> know the difference between dirnames and basenames
Yes, POSIX has a self-consistent definition of those terms.
> and that a dirname
> can only be treated as a basename when it has been emptied of files.
No, that is not a consistent statement in light of the POSIX definition
of the terms.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 13 Sep 2012 00:52:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 12339 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 09/12/2012 06:28 PM, Eric Blake wrote:
>> Before, "rm -r bbb/" was not valid syntax --
>
> Sorry, but 'rm -r bbb/' has ALWAYS been valid syntax in POSIX, and has
> always meant 'remove the directory found by resolving 'bbb', even if
> 'bbb' is a symlink to a directory. The fact that the Linux kernel
> rmdir("bbb/") has not always followed POSIX in this regards makes it
> harder to use as a use case - because then we are torn with whether to
> honor the kernel decision of how it should behave or whether to pay the
> penalty of a slower wrapper function that does it the way POSIX says it
> should behave.
On re-reading this, I think a bit more on this topic might help.
Remember that remove() is required to call either rmdir() or unlink() as
appropriate.
On Solaris 10, if 'bbb' is a symlink to an empty directory, then
remove("bbb") removes the symlink but leaves the directory; and
remove("bbb/") removes the directory, but leaves bbb as a danging
symlink. This is the behavior POSIX mandates, but can be non-intuitive
if you are not expecting it.
On Solaris 8, remove("bbb/") had a bug where it silently ignored the
trailing slash, and was blindly treated as remove("bbb"). Even if "bbb"
was some other file type, like a regular file, it was still removed.
Coreutils works around this bug by using a gnulib module to wrap a large
number of Solaris 8 kernel calls that silently ignore trailing slash.
On Linux (at least through kernel 3.5.3), remove("bbb") removes the
symlink, and remove("bbb/") fails with ENOTDIR, which is contrary to
POSIX. The failure intuitively makes more sense (who wants to leave a
dangling symlink behind?), although the choice of errno value does not
(POSIX requires that bbb/ be treated as a directory, and the symlink
does indeed resolve to a directory). But gnulib and coreutils so far
have chosen not to penalize Linux with a wrapper around remove(), and
instead this means 'rm' currently ends up with non-POSIX behavior
because the kernel still has non-POSIX behavior.
On all three systems, remove("bbb/.") fails, consistent with the POSIX
requirement that the basename of "." cannot be removed directly, but
only by rmdir()ing another name for the same directory. In this case,
POSIX mandates EINVAL as the failure (not all systems meet this), which
is different than the ENOTDIR failure of Linux' remove("bbb/").
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 13 Sep 2012 01:22:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 12339 <at> debbugs.gnu.org (full text, mbox):
Eric Blake wrote:
> On 09/12/2012 04:51 PM, Linda Walsh wrote:
>> I hope to prove the subject convincingly in the following sections, If
>> you can, reading this in the original HTML might be useful, as I don't
>> know it will end up when converted to text.
>
> the mail engines sripped it to
> plain text before it ever hit the list or the online bug report:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12339#239
----
Doesn't look like it. I sent it in plain and HTML, and it
displays the plaintext as formatted by Thunderbird, by default, and
has a link to the second part where it has stored the original.
Seems your db-bug report engine is smarter than you give it
credit for -- that and my deliberately including a plaintext version
that would try to represent the formatting as closely as possible.
> So please bear with me if my inability to see your intended markup means
> that I misinterpret your intent.
---
If you want to see the html copy, it kept it at:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=239;att=1;bug=12339.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Thu, 13 Sep 2012 02:50:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 12339 <at> debbugs.gnu.org (full text, mbox):
Eric Blake wrote:
> They are also well-defined terms in the POSIX standard.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_40
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
>
> Let's look at some different "Cases" of sample pathnames (skipping
>> the easy ones, given the audience):
>>
>> Case A: "/" What is the dirname and what is the basename?
>>
>> Answer: <null> and <null>.
>
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions. The POSIX-mandated answer is a dirname of '/' and a
> basename of '/'. Additionally, this particular file name is always a
> directory.
----
I admit, you are half right.
It says to return a directory indicator for a basename ... which I find
absurd, however, it says to strip off the '/' for a dirname and only return the
parent.
Specifically:
The dirname() function shall take a pointer to a character string that contains
a pathname, and return a pointer to a string that is a pathname of the parent
directory of that file. Trailing '/' characters in the path are not counted as
part of the path.
So even if the parent was "/", it is not to count as part of the path.
There is no place on disk or in the the OS that calls the root dir "/", a rootfs
is mounted
at /, but that's not the name of the rootfs.
>
>> Case B: "ENTRY/" What is the dirname and what is the basename?
>>
>> Answer: Dirname="ENTRY", basename=<null>. (Explanation seems unnecessary).
>
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions. The POSIX-mandated answer is a dirname of '.'
----
But that is semantically incorrect. They can define it that way, but semantically
that isn't consistent with existing implementation.
Example:
Is "find" POSIX compatible? Typing "find DIR", doesn't
yield output of ./dir -- yet that would be required if it followed those rules.
>> Case C: "ENTRY" Dir and Basenames?
>>
>> Answer: it depends on context and what it really is.
>
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions. The POSIX-mandated answer is a dirname of '.' and a
> basename of 'ENTRY'. But you are correct that it may or may not be a
> directory.
---
yet it is consistent with current implementation and POSIX is meant
to be _descriptive_ not _prescriptive_, therefore it is POSIX that is not matching
implementation.
People need to read the preamble to POSIX. If the implementation they have
doesn't match what POSIX describes, then POSIX has err'ed.
>> Whether or not 'ENTRY' is a basename or a dirname depends on whether or
>> not 'ENTRY' is a directory.
>
> Rather, the POSIX definition states that 'ENTRY' is a basename because
> it is the last non-slash component of the overall string, after
> stripping any trailing slashes. Remember, a directory is ALSO a file,
----
It can only be treated as a file when it is empty. then one can
issue a single command for it's removal. Otherwise, a directory is more
than just a file.
> just like a symlink or a socket or a character device is also a file.
> The term basename applies to any file, not just non-directory files.
----
This
>
>> Example. In it's default mode rm removes only files.
>
> Correction - in its default mode, rm removes regular files, symlinks,
> fifos, block devices, character devices, socket files, and any other
> implementation extension file types, but has special case treatment of
> directory files.
-----
One just said a symlink, socket or char device are files... so what
is being corrected by by the above statement?
AFAIK, I'm I'm differentiating between files entries in a directory and
directory entries that contain other files. If the directory
contains nothing and is empty -- it can, 'effectively', be treated as a file,
and removed
with it's type-specific-removal operation.
Directories need more than simple unlinking because they are not simply 'entries',
they are objects with references to other objects (including itself). Those need
special handling to be deconstructed by the OS. They are not files that the
user has control
over nor that POSIX should be trying to claim control of.
> this special case treatment is mandated by POSIX, to match historical practice.
---
Not exactly true. It's because it is mandated OS function and POSIX is
descriptive.
(which could be two ways of saying the same thing, but it is not solely for
historical
benefit).
>
>> "rm a b c ENTRY d" -- rm expects all entries to to simple basenames. If
>> it encounters a dirname, it issues an error and refuses to operate on it.
>
> Correcting your terminology:
> If it encounters a *directory*, it issues an error and refuses to
> operate on it.
---
If it encounters a 'name' that is a directory name. That's what
I am calling a dirname -- because that is what it *is*. It's descriptive
of it's function.
POSIX is suppose to be descriptive. If it is not, then it is failing.
>> In it's recursive mode, rm will accept basenames and dirnames. It will
>> inspect each entry to determine if it is a file (basename) or a
>> dir(dirname).
> Again correcting your terminology:
my terminology is accurate. It doesn't accept directories. It accepts
NAMES of directories. Don't confuse the name for the object. We have names
for objects, but the name is not the object. The directory is a container.
It has a name -- often called a directory name or dirname for short. But
that's just common sense. Yet you are saying under POSIX, normal common sense
and literal definitions do not apply. That's not being descriptive.
> rm will accept directories in addition to other file types.
---
No, it will accept directory names and handle them separately
and differently from every other entry in a 'dir'.
>> Only after the contents have been removed is it no longer a dirpath --
>
> This statement makes no sense in light of POSIX terminology.
---
POSIX is failing at it's job of being descriptive.
I was careful in choosing my words in writing the previous document,
as they were descriptively taken from their function in the OS. By using arbitrary,
POSiXELLIAN terminology you start being unable to describe what is and you start
to hinder communication. This is usually done by authoritarian entities to serve
their own ends.
>> There are 2 entries not covered usually covered by security policies, as
>> they are not discretionary entries -- they are mandatory components of
>> the OS, namely "." and "..".
>
> Actually, believe it or not, '.' and '..' are NOT mandatory directory
> entries in POSIX.
----
I didn't say it was mandatory in POSIX, just the OS -- that POSIX
isn't following its descriptive mandate is unsurprising.
>> As POSIX is a computer portability standard, one would imagine that they
>> know the difference between dirnames and basenames
>
> Yes, POSIX has a self-consistent definition of those terms.
----
Yes... a self, internally, *Orwellian*, *new-speak* definition.
> No, that is not a consistent statement in light of the POSIX definition
> of the terms.
---
In which they attempt to obfuscate function and thus, are demonstrably
not following their intended mission of being descriptive. This brings into
question whether or not they are *really* POSIX terms, or terms created and made
up by opportunists who see POSIX as a way to create and enforce their standard.
But clearly, they do so by violating POSIX's original charter/mission statement.
Doesn't that mean their statements and words are not POSIX compliant and can't
be considered as POSIX?
You see, that's where I break with POSIX -- I was all for POSIX compliance
as a descriptive standard... but as soon as they changed from descriptive to
prescriptive, they became 'not-POSIX' anymore.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12339; Package
coreutils.
(Fri, 18 Jan 2019 09:30:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 12339 <at> debbugs.gnu.org (full text, mbox):
close 12339
stop
(triaging old bugs)
Hello,
This long and winding thread covers several topics
relating to rm(1), historical unix and POSIX compatibility
(and a bugfix or two in the mix).
An enlightening read for those interested...
( https://bugs.gnu.org/12339 )
But the bottom line is:
rm -rf .
will not delete the content of the current directory
(while keeping the directory itself) and that is not likely to change.
Two suggested alternatives:
find . -delete
rm -rf * .[!.] .??*
As such, and with no more comments in 6 years, I'm closing this bug.
PLEASE do not reply to this thread.
If there are other relevant issues (that have not been discussed
elsewhere, and have not been previously rejected),
please start a new thread by emailing coreutils <at> gnu.org .
regards,
- assaf
bug closed, send any further explanations to
12339 <at> debbugs.gnu.org and Linda Walsh <coreutils <at> tlinx.org>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 18 Jan 2019 09:30:04 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 15 Feb 2019 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 80 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.