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

[Bernhard Voelker]

On 11/21/2013 02:39 PM, Eric Blake 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 and
> so the overall rm command fails, or by explicitly skipping the attempt
> to rmdir(".") and letting rm succeed).  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 ".".

I realized the difference when reading her latest message. (It's often
hard to follow her; sorry Linda.)

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

Okay, I see the point: so now we're talking about the following
(with "." to be allowed instead of 'dir'):

  $ mkdir dir dir/sub

  $ touch dir/file dir/sub/another

  $ rm -rv --children-only dir
  removed 'dir/file'
  removed 'dir/sub/another'
  removed directory: 'dir/sub'
  retaining directory argument due to --children-only: 'dir'

  $ ls -d dir
  dir

I'm not happy with the semantic as the difference to all other existing
uses of rm(1) would be that the argument is explicitly not removed,
but well, ...

Such --children-only would require some extra checking on arguments,
because only arguments of type directory are allowed.
And there'd be some strange corner cases to decide about, e.g. consider
  rm -r --children dir/sub dir
Should "dir/sub" be removed/retained in this case? ...
Anyhow, handling such cases would add considerable bloat to the code.

Does anyone know of such an option in other rm(1) implementations?

Have a nice day,
Berny