[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rmdir -p
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
Main Index |
Thread Index |