Re: rmdir -p foo/bar/nonexistent

[Koblinger Egmont]

On Mon, Apr 10, 2006 at 11:28:27AM -0700, Paul Eggert wrote:

Hi,

> You can work around most of the problem in a script as follows:
> 
> test ! -e "$dir" || rmdir -p "$dir"

No, this is the reverse workaround. This would mimic the current behavior of
"rmdir -p" if rmdir was actually changed as I recommend.

To create a global solution for my needs with the current rmdir, at least a
shell loop is required, somehow like this (I haven't tested it):
        rmdir -p "$dir"
        while [ "$dir" != "${dir%/*}" ]; do
                dir="${dir%/*}"
                rmdir -p "$dir"
        done
Maybe it's not the simplest way to do it, but the loop cannot be eliminated,
so it'll sure be more complicated than a simple "test ... || ..."

> If there's a real need for an option that works the way you suggest, I
> suppose it could be added; but it shouldn't be called "-p".

Shortly summarizing my goal: I'm writing scripts for a package build system.
Some packages create directories like /usr/share/applications and then don't
put any .desktop files in them (this is just one example from several
similar directories), or maybe during file split amongst several binary
packages this directory remains empty in one of the subpackages. However, I
don't want any package to ship an empty /usr/share/applications, so I'd like
to remove it. Furthermore, I don't want an empty /usr/share or
/usr either, no matter if usr/share/applications was created or not before.
Hence first I put this in one of the scripts:
  cd $DESTDIR
  rmdir -p --ignore-fail-on-non-empty usr/share/applications 2>/dev/null
but when I realized this didn't work the way I expected it if "applications"
didn't exists, I had to change it to this:
  rmdir -p --ignore-fail-on-non-empty usr/share/applications usr/share usr 
2>/dev/null

I don't know if there is a real need for this option, for me it is not very
important since I have fixed paths so I could hardcode the prefix paths and
didn't even need a loop. I just believe that -p would be more logical in the
way I recommend it, and the workaround for the other behavior would be more
simple then. OTOH I don't think this woule issue is so important that it
would worth it to introduce a new option.



thanks,

Egmont