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

[Pádraig Brady]

On 11/21/2013 01:39 PM, Eric Blake wrote:
> On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
> 
>>
>> Admittedly, compared to the academic question behind "--no-preserve-root"
>> (which is like "what happens to me when the globe under my feet 
>> disappears?"),
>> there may be more real-world reasons to remove ".".
> 
> 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.

I'm not that enthusiastic for this new option,
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be used to handle arbitrarily
many files and commands that don't support recursion internally.

Could you explain why rm would get this and say chmod would not?

thanks,
Pádraig.