bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request: rm should implement option -p, --parents


From: Pádraig Brady
Subject: Re: Feature request: rm should implement option -p, --parents
Date: Mon, 6 Jul 2009 17:00:10 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20071008)

Guido Flohr wrote:
> Hi,
> 
> desired behavior:
> 
>     $ mkdir /usr/share/myapp
>     $ mkdir /usr/share/myapp/pixmaps
>     $ mkdir /usr/share/myapp/pixmaps/8x16
>     $ install -m 644 icon.png /usr/share/myapp/pixmaps/8x16/

The above can be simplified to:

dir="/usr/share/myapp/pixmaps/8x16"
install -d "$dir"
install -m 644 icon.png "$dir"

> Uninstalling with clean up in such cases is a frequent task, and could be 
> greatly simplified by:
> 
>     $ rm --parents /usr/share/myapp/pixmaps/8x16/icon.png
>     rm: failed to remove `/usr/share': Directory not empty
>     $ ls /usr/share/myapp
>     ls: cannot access /usr/share/myapp: No such file or directory
> 
> The idea is to remove the containing directory of a file recursively, 
> upwards, and stop that recursion on the first failure to remove a directory, 
> most probably because of ENOTEMPTY.

Would that not be better supported with:

rm "$dir/icon.png" && rmdir -p "$dir"

I can kind of see the benefit of your proposal in the
unusual case where $dir is not known. But then one can do:

rm "$file" && rmdir -p $(dirname "$file")

> The same idea could be applied to chmod, chgrp, and chown.

So you mean assume empty directories above the file belong with
the file, and so change the permissions and ownership accordingly.
Would that not be better supported with `install -d` ?

cheers,
Pádraig.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]