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

From: Linda Walsh <[email-masked]>
Date: Thu, 21 Nov 2013 10:05:06 -0800

On 21/11/2013 09:50, Bob Proulx wrote:
> Eric Blake wrote:
>> P�draig Brady wrote:
>>> 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?
> 
> Argh!  Feature creep!
> 
> The reason that rm should have it but chmod should not is that it is
> to work around the POSIX nanny rule around '.' and '..'.  Chmod does
> not have such a nanny rule and therefore does not need that option.
...
> This is actually the best argument against it.  It is a slippery
> slope.  Let's not implement 'find' all over again.
----
Let's just use '-F' to force "rm" to adhere to its original depth
first path examination.  "-F" disallows applying any path related
rules until AFTER depth-first recursive execution has been completed
on the path.