bug-coreutils
[Top][All Lists]
Advanced

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

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


From: Pádraig Brady
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 18:01:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.





reply via email to

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