bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 10:34:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 11/21/2013 10:18 AM, Bob Proulx wrote:
> 
>> 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
> 
> I am missing this part.  Why must it fail?  And in fact as per my test
> case above it succeeds.

No, if there were no nanny rule, then there is a difference between:

rm -r $PWD # Deletes dir out of under your feet, if allowed
rm -r .    # leaves dir empty

rmdir(pwd) can succeed (true on Linux; it can also fail if the system
deems that a directory in use as a pwd can't be deleted - mingw is one
such system)
rmdir(".") MUST fail (rmdir(2) can only delete a directory if specified
by a non-. name)

Linda was asking to delete children but NOT the directory; she did NOT
want to use 'rm -r $PWD' because that attempts (and may succeed) at
deleting pwd.  But she was ticked off that the nanny rules on "."
prevented recursion from even being attempted.

> 
> Agreed.  And I rather like the --children-only semantics you have
> proposed.  It creates a generally useful behavior regardless of other
> things.  It isn't quite the same as bypassing the nanny rule for '.'

Indeed - and if we still keep the nanny rule, then Linda would have to
use 'rm -r --children-only $PWD' because the nanny rule would block 'rm
-r --children-only .'; but since --children-only takes us out of the
realm of POSIX, we can also use it to skip the nanny rule.

> but it solves the issue while doing something generally useful at the
> same time.  Have to like it when it is two birds with one stone. :-)

Yay - I'm glad that we appear to have come to what seems to be a useful
conclusion.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]