bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use (original) (raw)


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


From: Bob Proulx
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 10🔞30 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

Eric Blake wrote:

But that's not what Linda is asking for. She is not asking to pull "." out of under her feet.

Actually as I understand it she is expecting the call to succeed if the system kernel allows it. I believe that is the way rm used to work before removing '.' was disallowed.

mkdir /tmp/testdir cd /tmp/testdir rmdir /tmp/testdir echo $? 0 ls -ldog /tmp/testdir ls: cannot access /tmp/testdir: No such file or directory /bin/pwd /bin/pwd: couldn't find directory entry in ‘..’ with matching i-node

That is fine in a flow such as a test flow or other where the action is cleaning up on an exit for example. Or in other cases. It might be making a new directory and changing to it afterward. Or something else that makes sense in that case.

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.

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

Agreed.

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.

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 '.' 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. :-)

Bob