bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Linda Walsh]

Bob Proulx wrote:
> Because I originally voted that this felt like a bug I wanted to state
> that after determining that this has already been legacy system
> historical practice for a very long time that I wouldn't change it
> now.  Portability of applications is more important.
----
        Right now, the feature is unused, So hurting compatibility
is not an issue - users can push for the feature on other systems as needed.

        It certainly isnt' a safety issue, since
rm **
on a bouncy keyboard is alot easier to type than rm -fr *,
and the former will remove all files under the current dir
(just none of the directories)

I suppose rm **;rmdir ** would work -- but but require SHELL.

I think adding the case of rm -fr . or (dirname/.) to delete contents
of the dir, but not the dir itself makes more sense and is safer than
the easier to type rm **


> This isn't a feature that could be working in a script for someone.
> It isn't something that was recently removed that would cause a script
> to break.  A script will run now with the same behavior across
> multiple different types of systems.  I think we should leave things
> unchanged.
----
        It's only been recently that I've noticed rm -fr . not working and
I can't figure out why since it hasn't been around for so long.

        
        Consider the parallel, if I want to make sure I copy the contents
of a dir, I need to use cp dir/. dest/

If I use dir/ or dir, they both end up in dest (even with the "/").

That means without using ".", the contents are not addressable, so what is
demanded by 'cp', is refused by 'rm'.

That is not a consistent user interface and is symptomatic of poor design.

Using "." to reference content of a dir is standard in other utils -- that
it doesn't work in 'rm' goes counter to the idea of how rm works -- you have
to remove contents before trying the current dir.  It isn't logical to think
that it would try the current dir before anything else -- as it goes completely
contrary to how rm has to work.

I say it's a design flaw and inconsistent with other programs.

But if I can set an env var and have it work on my system, someone else
can work to get the core utils to work consistently...