Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by jrw (1844) on 2010.01.11 12:49 (#71515)
    Obviously the trash can approach is a good one, but it does have its limitations. For example, if this is not your server, then who will take care of emptying the trash on a regular basis? Or, if you use the mv --backup approach, then what if your mv doesn't support the --backup option or if you don't want to see numbered backups of each file in your directory?

    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.

    • 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