GNU bug report logs - #15926
RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

Previous Next

Package: coreutils;

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


Message #83 received at 15926 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15926 <at> debbugs.gnu.org, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#15926: RFE: unlink command already uses 'unlink' call; make
 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 07:42:58 -0800
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.