On 11/21/2013 10:50 AM, Bob Proulx wrote:

>>> Could you explain why rm would get this and say chmod would not?
> 
> Argh!  Feature creep!

Maybe, but it certainly seems like a useful feature.

> 
> 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.

chmod -r $mod .

will change the permissions on '.'.  POSIX has a nanny rule about 'rm -r
.', but it ALSO forbids rmdir(".").  But the reason it has no nanny rule
for 'chmod -r .' is because chmod(".", mod) is allowed.  There is NO way
with existing chmod to change the permissions on children but not on
chmod itself; you'd have to resort to 'find . -! -name . -exec chmod
$mod {} +'.

Doing a recursive action on children only IS a useful paradigm in
parent/child trees.

> 
>> Ideally, any command that implements recursion should have the option to
>> operate on children only.  You are correct that rm should not be special
>> in this regards, so yes, I think chmod should also get it.
> 
> This is actually the best argument against it.  It is a slippery
> slope.  Let's not implement 'find' all over again.

If you are arguing that 'find' be the only program that implements
"recursion but leave the root alone", then Linda's counterargument of
needing a way to call remove() instead of unlink() when using 'rm'
instead of 'rm -r' is in effect; but we already demonstrated that our
extension of 'rm -d' serves that purpose.  It's just that 'find . -depth
-! -name . -exec rm -d {} +' is a lot more typing than 'rm -r
--children-only .'.

At any rate, since both BSD and GNU rm had 'rm d', I'm going to submit a
bug to POSIX to request its standardization.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org