coreutils
[Top][All Lists]
Advanced

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

Re: a smarter rm


From: Diggory Hardy
Subject: Re: a smarter rm
Date: Wed, 24 Apr 2013 14:06:32 +0200
User-agent: KMail/4.10.2 (Linux/3.5.0-27-generic; KDE/4.10.2; x86_64; ; )

> 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

...at which point hopefully people would find it useful.

My aim was to make rm easier to use without losing prompts where data loss 
might occur, which your suggestions don't actually solve (particularly in that 
behaviour using your scripts is nothing like transactional, in that if one 
discovers some files he/she didn't realise were there it might be preferable 
not to have the empty directories and links removed either).

But never mind, having played with my script a bit I find the expected 
behaviour when encountering non-empty directories is not trivial, so this is 
probably not a feature worth bloating rm for.

> 
> > 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.




reply via email to

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