bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/.

[Linda Walsh]

Paul Eggert wrote:
> Linda Walsh wrote:
> > > time rm -fr .
> > 183.23sec 0.69usr 36.25sys (20.16% cpu)
> > > time find . ! -name . -prune -exec rm -fr {} +
> > 219.58sec 0.87usr 40.81sys (18.98% cpu) -- about 36 seconds (~20%) longer
>
> Benchmarks like this are often suspect since a lot of it depends on 
> factors that are hard to reproduce.  That being said, when I tried a 
> similar benchmark on my machine, the 'find' solution was over 30% 
> faster. 
---
        Nearly impossible except for leaving out that that find DOES have
some multi-cpu capability in it's system scan, If rm had the same,
then the addition of 500,000+ calls to an external process can't take
'zero time'.

In any event the minor performance improvements we're talking 
> about would not be a compelling argument for adding UI complexity to 
> 'rm', even if the 'rm' approach was uniformly faster
>
> > But you also didn't address points (3), (4) or (5)..
>
> They aren't a problem either.  As I mentioned, the "find" approach 
> conforms to POSIX and so is quite portable; that covers (3).  
----
        You claim it adheres to POSIX, but there is no single POSIX --
what version are talking about, as the version of POSIX from 2003 or 
earlier wouldn't have problems.

        POSIX was supposed to describe what was actually implemented
in the systems out there so people could move to a common base to
provide API compatibility.   Adding descriptions of the base commands
and the arguments supported was to help write shell scripts that
would be portable.  Removing functionality in a backwards incompatible
way is anything but "helping portability".  (3) is not maintained.

> If you 
> don't want to cross file system boundaries, add the POSIX-required -xdev 
> option to 'find' and the GNU extension --one-file-system argument to 
> 'rm'; that covers (4). 
----
        Not really -- we are talking about the 'rm' command.  Not rewriting
scripts and humans to use new commands.  

        Answer this:  How does disabling functionality make something more
portable?  Gnu coreutils have tons of things that enable new functionality, 
that are not portable unless you assume all platforms will have the new
functionality.  But **removing** capabilities from programs can never 
provide backwards compat -- rm -fr dir/. was there for 30 years, and now
you think removing that feature makes it portable?  I'm sorry, your logic
is not logical.

        If you want to use the safety reason as an overriding reason then
I can see banning . .. and / (even though gnu went for a workaround on
/.  But safety wouldn't be an excuse for removing rm -fr "this_is_a_dir/.".
I've never even heard of '.' being aproblem and it is supported in the rest
of coreutils (except rmdir -- where dirname_this_is/. should also be allowed.

> People that don't keep up-to-date can't rely on any changes that we 
> would make to 'rm'. 

        I keep up-to-date -- that's why it bit me.  But I still haven't
upgraded my perl beyond 5.16 because too many of my script break due to
them installing or removing various supported featers.  I'm still working
on that -- but it's alot of scripts.

> I ran my little test on the same file system.

Did you at least drop the caches between runs (i.e.)
by echoing '3' to /proc/sys/vm/drop_caches?  

> I'm afraid I'm not persuaded.

You really think when people find they can't do: 

> cp -axf /usr/. /usr2/.    #... no wanted that in /usr3
> mkdir /usr3 && cp -alxf /usr2/. /usr3/.  ... ESPACE...!
> rm -fxr /usr2/. /usr3/.   ## except this will fail...
> cp -axf /usr/. /usr3/.

They'll instantly think of find? -- Where else besides
rmdir is dir/. banned?