bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

On 11/21/2013 07:42 AM, Bernhard Voelker wrote:
> I'm not happy with the semantic as the difference to all other existing
> uses of rm(1) would be that the argument is explicitly not removed,
> but well, ...

Such is life - and that's why it requires a new long option.

> 
> Such --children-only would require some extra checking on arguments,
> because only arguments of type directory are allowed.

That's one idea.  Another idea is to make the option handle directories
specially but have no change for regular files (similar to how 'rm -d'
handles directories specially but has no change for regular files).

> And there'd be some strange corner cases to decide about, e.g. consider
>   rm -r --children dir/sub dir
> Should "dir/sub" be removed/retained in this case? ...

Removed; as always, rm processes command line arguments in order, so
even though dir/sub is left alone after the first argument is processed,
the second argument removes dir/sub without any care in the world what
processing the first argument did.

> Anyhow, handling such cases would add considerable bloat to the code.

Hard to say that it is considerable bloat without seeing a patch; we
already know when the top-level arguments are directories thanks to 'rm -d'.

> 
> Does anyone know of such an option in other rm(1) implementations?

Not in rm(1) per se, but I _do_ know that the paradigm is common in
other hierarchical based systems.  For example, in libvirt, you can
maintain a tree-based view of snapshots, and for removing a branch of
that tree, libvirt exposes the option to either remove a snapshot and
all its children, or to just remove the children but leave the snapshot
intact.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature