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

    • 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 happens, and you notice a split second later, but the die has already been cast. The decision to use -f comes too early, you don't decide to make a slip, but you have to decide to use -f. Same with any sort of "yes to all". Users have to be able to make the slip and then recover from it.

      The alternative is careful checking of every move, which is slow and frustrating and will eventually fall by the wayside.