NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Donald E. Knuth
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
A different approach (Score:1)
I've taken a different approach, which I haven't seen anyone mention anywhere else and which is universal across all unixes: I alias rm to a short script (rmx) which checks: Has any option been given? If so, then just do it. If not, how many filenames are being removed? If just one and either that filename is a file or symlink, then just do it. Otherwise, list all the filenames to be removed and prompt for confirmation before doing it.
This has the big benefit of allowing the common case where you specify the file to be removed with a wildcard and protects you when your wildcard accidentally matches more than one file. If you really want to remove more than one file, then either answer the prompt YES or specify -f.
My rmx script only allows a limited number of options (f,i,r,R) which are all I need at the command line.
The one drawback of all the "aliasing" approaches is that you become used to the "safety net" of your alias and might be more inclined to make a mistake on a system where your safety net is not in place for the user you're logged in as.
Reply to This
Re: (Score:2)
The point was not the details of the implementation, you can write trash dozens of different ways and trash automation isn't necessary its just convenient. The point is the interface, what its training the user to do and if its really protecting against the consequences of slips.
Your solution still contains the key problem: training the user to ignore the prompt. It just reduces it somewhat, but the really annoying case remains: the big list of prompts. Yes. Yes! YES! YES!!
Slips are something that hap