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): 8.21-11 How reproducible: Always Steps to Reproduce: 1. man rm 2. 3. 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.
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. thanks.
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!
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.
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.
Created attachment 769844 [details] improved patch for rm -m Attached is improved patch so that "rm -m -f" works as expected.
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 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).
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.