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

[Jim Meyering]

On Thu, Nov 21, 2013 at 5:39 AM, Eric Blake <address@hidden> 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.