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

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Tue, 19 Nov 2013 11:58:02 UTC

Severity: normal

Tags: notabug, patch

Merged with 15943

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 15926 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 08:06:22 -0700
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, attachment)]

This bug report was last modified 6 years and 225 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.