Bug 981845 - rm -I option inadequate
rm -I option inadequate
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-07-06 05:18 EDT by JW
Modified: 2016-05-12 07:42 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-12 07:42:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
add -m option to rm (3.07 KB, patch)
2013-07-07 00:44 EDT, JW
no flags Details | Diff
improved patch for rm -m (4.03 KB, patch)
2013-07-07 01:09 EDT, JW
no flags Details | Diff

  None (edit)
Description JW 2013-07-06 05:18:32 EDT
Description of problem:
Although the 'rm' utility has a -I option the coder has arbitrarily decided that more than 3 files is the magic number of files which determines whether a prompt to remove is issued or not. So why wasn't the -I option simply allowed to take an arg such as "-I 3" or "-I 1"?  Hard coding some arbitrary number according to the preferences of one individual programmer is very poor form. Why provide a crippled option?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. man rm

Actual results:
1. -I     prompt once before removing more than three files

Expected results:
1. -I NUM    prompt once before removing more than NUM files

Additional info:
The older bsd-style rm had a very nice feature by default. It would prompt if more than one file was provided on the command-line (say, as result of wildcard expansion). That would be equivalent to "-I1". Very difficult to understand what anyone would arbitrarily hard-code the number 3 into the rm.c source.
Comment 1 Pádraig Brady 2013-07-06 06:40:01 EDT
Well optional arguments to short options are very problematic and avoided at all costs. Also -I aligns with the same behavior with BSD rm.
So with my upstream coreutils maintainer hat on,
I'm closing this as not something we wouldn't consider.
Feel free to reopen/debate here if you feel strongly about it.

Comment 2 JW 2013-07-06 07:05:16 EDT
For me the solution is simple - I have patched my copy of coreutils to fix it.

But what gets me ... who was the idiot who added a -I option without an arg? More ancient bsd (which I once used to use) had a default which was in effect -I1 and I found that to be ten times better than system V and other derivatives.

You could always add a new long arg, such as --prompt-level, and leave the -I arg alone.

Why not do that??  Then everyone would be happy. It isn't exactly rocket science!
Comment 3 JW 2013-07-07 00:44:38 EDT
Created attachment 769836 [details]
add -m option to rm

Adds a -m option (m for multiple, as in prompt iff multiple files specified on command-line).  There is also a matching --interactive=multiple option. Provides better protection against accidental file deletion than -I.
Comment 4 JW 2013-07-07 00:47:04 EDT
Regards the patch:

IMO the -m option provides far better, and more specific protection against inadvertent accidental removal of files. Given files aa, ab, and ac then "rm -I a*" provides absolutely zero protection, whereas "rm -m a*" certainly does".

The worst, and most unfortunate, feature of the -I option is that when more than 3 files match the prompt gives absolutely zero information as to which files matched.  Conversely, the -m option clearly, and interactively, shows the matching files.
Comment 5 JW 2013-07-07 01:09:06 EDT
Created attachment 769844 [details]
improved patch for rm -m

Attached is improved patch so that "rm -m -f" works as expected.
Comment 6 Ondrej Vasik 2013-07-09 03:13:53 EDT
JW: thanks for the suggestion and patches - anyway, this is not something what we should add as downstream patch and upstream will not be very keen about new short option for rm unless there is strong justification for it. Could you please propose your patches on coreutils@gnu.org mailing list (with justification for the -m option)? Having this on Red Hat/Fedora Bugzilla keeps the audience very limited.
For Fedora, this is most likely WONTFIX unless accepted upstream (and Pádraig wrote his upstream opinion about optarg for -I in comment#1 and I know how hard it is to get new short options to the fundamental utilities like rm).
Comment 7 Kamil Dudka 2016-05-12 07:42:32 EDT
The upstream maintainer has been notified about the proposal.  I am closing the bug as UPSTREAM.  Please feel free to continue the discussion on the upstream mailing-list.

Note You need to log in before you can comment on or make changes to this bug.