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
signature.asc
Description: OpenPGP digital signature
