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: Bob Proulx
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 10:18: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





reply via email to

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