Re: rmdir -p

[Geert Hendrickx <ghen%telenet.be@localhost>]

On Mon, May 19, 2008 at 11:45:40AM -0400, D'Arcy J.M. Cain wrote:
> On Mon, 19 May 2008 10:20:15 +0200
> Geert Hendrickx <ghen%telenet.be@localhost> wrote:
> > On Sun, May 18, 2008 at 09:49:29PM -0400, D'Arcy J.M. Cain wrote:
> > > Is the following the correct behaviour?
> > > 
> > > $ mkdir /tmp/rmdirtest
> > > $ mkdir /tmp/rmdirtest/x
> > > $ mkdir /tmp/rmdirtest/x/y
> > > $ touch /tmp/rmdirtest/z 
> > > $ rmdir -p /tmp/rmdirtest
> > > rmdir: /tmp/rmdirtest: Directory not empty
> > 
> > Yes, rmdir -p will try to go *up*, not down in the directory tree.  In your
> > example, "rmdir -p /tmp/rmdirtest/x/y" will remove /tmp/rmdirtest/x/y and
> > /tmp/rmdirtest/x but not /tmp/rmdirtest because the latter is not empty.
> 
> Yes, of course.  My question is, why throw an error if the named tree
> has been pruned as much as it can be.  I can understand an error if I
> give it a path that doesn't exist and I am certainly happy that it
> stops removing directories when it hits a non-empty one because that's
> what I asked for.
> 
> If I asked a gardner to prune a rose bush and he sliced it off at the
> root I would be upset.  If he removed dead branches and left the useful
> ones I would not claim that he had done a bad job.  He did exactly the
> job I asked for.


I was just explaining the documented behaviour of rmdir -p and why it did
not do what you expected.  Don't blame me for the (apparantly) broken
package, please.

        Geert