GNU bug report logs -
#15926
RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Previous Next
Reported by: Linda Walsh <coreutils <at> tlinx.org>
Date: Tue, 19 Nov 2013 11:58:02 UTC
Severity: normal
Tags: notabug, patch
Merged with 15943
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Thu, Nov 21, 2013 at 5:39 AM, Eric Blake <eblake <at> redhat.com> wrote:
> On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
...
> But that's not what Linda is asking for. She is not asking to pull "."
> out of under her feet. Instead, she wants a command that will
> recursively remove the children of ".", but then leave "." itself
> unremoved (whether by virtue of the fact that rmdir(".") must fail and
> so the overall rm command fails, or by explicitly skipping the attempt
> to rmdir(".") and letting rm succeed). Right now, the nanny rule of
> POSIX is preventing the recursion, so you have to use contortions such
> as the POSIX 'find . -depth ! -name . -exec rm {} +'. So I think it IS
> useful to add an option that forces 'rm -r' to bypass the nanny rule and
> recurse on ".".
>
> Maybe naming it --no-preserve-dot is wrong. Maybe a better name is 'rm
> -r --children-only .'. At which point, I would much rather see us skip
> the rmdir(".") in order to allow rm to succeed. And it would also work
> even for non-dot situations: 'rm -r --children-only dir'. In other
> words, I _do_ see what Linda is asking for, and think it is worth providing.
Thanks for clarifying, Eric. I am open to the idea. Amusingly,
when I first read your suggestion for --children-only, I thought,
"That's backwards, shouldn't it be '--adults-only' to go with the
no-nanny semantics?" Of course, "children" refers to tree parent/child
relationship, so would make sense in the manual, where there's no
talk of removing this nanny-like safeguard. But then I wondered about
non-directory arguments, and how the implied semantics of --children-only
applies (or not) to them. I don't particularly like the idea of adding
the long-named --(no-)?preserve-dot-or-dot-dot, because that would
render ambiguous any existing use of --(no-)?preserve- and all shorter
abbreviations of --(no-)?preserve-root.
This bug report was last modified 6 years and 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.