[Top][All Lists]

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

Re: a smarter rm

From: Eric Blake
Subject: Re: a smarter rm
Date: Tue, 23 Apr 2013 18:02:22 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5

On 04/23/2013 01:52 AM, Diggory Hardy wrote:
> Dear list,
> I have been playing with some changes in behaviour to make 'rm' smarter / 
> friendlier. (See my_rm in [1] for an implementation.)
> [1]: "my_rm"
> I'm not quite sure if I dare suggest changes in the behaviour of such a 
> standard and long-existing tool, but adding a -s ("smart") option (or 
> possibly 
> adjusting the -i behaviour) to do the following really seems to make it nicer 
> to use:

Have you tried using the existing rm -I instead of rm -i?

At this point, burning a new short option -s is undesirable unless there
is an existing implementation that has already used it for the same
purpose.  Adding a long option might be reasonable, but only if we think
the feature is useful.  Even then, it would take a while before that new
option percolates onto enough machines for you to assume it exists by
default, at which point

> 1. Don't prompt about actions which can easily be undone (assuming an "ls -l" 
> before hand): delete symbolic links and empty directories without question.

This is already relatively easy to do without bloating 'rm', by using
specific options to find (here, assuming GNU find extensions):

find -type d -empty -exec rmdir {} \; -o -type l -exec rm {} \;

> 2. Prompt before other actions (deleting files or recursively deleting 
> directories)

Isn't that what -i/-I already does, once the easy files are out of the
way?  And again, you could set up a find expression that filters out the
easy files and passes the remaining files to rm -i.

> 3. Don't require rewriting (using rmdir or -rf)

I don't follow what you are asking for on this step.

> Thoughts? Can a small improvement which shouldn't affect most scripts win out 
> over tradition?
> Please CC me, I'm not on the list.

That's list policy :)

> Diggory

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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