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

Previous Next

Full log

Message #128 received at 15926 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15926 <at> debbugs.gnu.org, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#15926: RFE: unlink command already uses 'unlink' call; make
 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 18:01:35 +0000

On 11/21/2013 05:39 PM, Eric Blake wrote:
> On 11/21/2013 10:38 AM, Eric Blake wrote:
>> On 11/21/2013 10:35 AM, Pádraig Brady wrote:
>>> as I don't see it as specific to rm.
>>> I.E. other tools like chmod etc would have the same requirement,
>>> and they might be handled with various shell globbing constructs.
>>> Even more generally find(1) could be used to handle arbitrarily
>>> many files and commands that don't support recursion internally.
>>>
>>> Could you explain why rm would get this and say chmod would not?
>>
>> Ideally, any command that implements recursion should have the option to
>> operate on children only.  You are correct that rm should not be special
>> in this regards, so yes, I think chmod should also get it.
> 
> Which says that maybe gnulib's fts module needs a new flag for recursion
> without visiting the root node, rather than adding ad-hoc root node
> exclusion into all clients.

That would be the right way to implement it,
_but_ the disadvantage is that this filtering
option is exposed to the users for all these commands.

I'm not sure it's useful enough functionality to expose,
and personally I'd use something like:

children() { find "$1" -maxdepth 1 -mindepth 1; }
or
children() { find "$1" | sed '1d'; }

and then...

children $dir | xargs rm -r

cheers,
Pádraig.

Previous Next

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