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

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Tuesday December 30, 2008
07:41 PM

alias rm "rm -i" (slips vs mistakes)

[ #38188 ]

This came up on hates-software recently. I have a special hate in my heart for this one. It's one of those special "helpful enhancements" which is both inconvenient and fails to do its job.

$ rm *
rm: remove regular file `foo.txt'? y
rm: remove regular file `bar.txt'? y
rm: remove regular file `this.html'? YES
rm: remove regular file `junk.html'? YES!
rm: remove regular file `temporary.tmp'? YES GOD DAMNIT
rm: remove regular file `important.txt'? YES
...
Wait, NOOOOOOOO!!!!!!!

This is the "are you sure?" anti-pattern, where the computer second guesses every potentially irreversible command issued by the user. The Microsoft approach. It results in slow interactions and a frustrated user trained to reflexively hit "yes" before comprehending the warning. By the time they do, it's too late.

This design ignores that there's a differences between a mistake and a slip. A mistake is when the user really doesn't know what they're doing. A slip is when they do know what they're doing, but have a temporary lapse. Many programmers assume users are idiots, that everything is a mistake, and don't account for slips.

Here's what the dialog would look like with the buttons taking slips into account. (I can't take credit for this one, I saw it at YAPC St. Louis)

  ------------------------------------------------------
               Remove file "foo.txt"?
 
  [Yes] [No] [No, but I meant Yes] [Yes, but I meant No]
  ------------------------------------------------------

You can't really make slips go away, everyone slips up. All you can do is reduce their chance of occurring (which is another show) and most importantly, lessen their impact. One simple way to do that is by turning an irreversible action into a reversible one. That is, provide an undo button. Or, in terms of deleting files, a trash.

$ cat ~/bin/trash
#!/bin/sh
 
mv --backup=numbered "$@" ~/.Trash/

IF you're going to monkey with rm to try and protect the user, make it move files to the trash. It doesn't break the outward interface (making it honor rm's flags is left as an exercise for the reader), and it actually does its intended job instead of just being broken, useless and annoying. Coupled with an automatic trash reaper (a cron job to delete the oldest files when the trash hits a certain size), and with hard drives sizes being what they are, most desktop users will never notice.

Slips happen. Cushion the blow.

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.
  • It's not something I thought about until one of our R&D engineers mentioned the idea of a "universal undo". For example at the site I work at, we build medical infusion pumps - one end has drugs in a syringe the other end has you. Death by decimal, as it's called is a serious issue and the R&D types take it very seriously. For example if you switch our pumps off it doesn't actually switch off or say "Are you sure?" is starts a count down which the user needs to keep hold of the off button or it carr

    --
    -- "It's not magic, it's work..."
    • Killing the patient is the one thing you can't undo.

      As for universal undo, I've seen elements of this. VMS' versioned filesystem (every time you write to a file it saves a new copy). Smalltalk's everything-is-an-object gives you interesting opportunities for universal undo like a paint program where every brush stroke is stored as a separate object that can be manipulated after the fact. No having to plan out your layers before hand. Emacs' obscenely large kill buffer is another, other apps have that as

      • Killing people is bad, our sales don't do well at all if that happens. Ironically the marketing droids boast about how complex our proprietary software is, when in fact that's probably not something that is not a good feature - thankfully the software is actually quite simple and there is less to go wrong which is actually not bad at all. Obviously we do make it better every release...

        Continuous Data Protection is a trendy form of backup - every change to the filesystem is logged and can be rolled back. Sup

        --
        -- "It's not magic, it's work..."
  • You can't protect the stupid and/or the impatient from themselves. :) For everyone else, there are snapshots and backups. :) Natch.
    • It's important to realize that the user is not stupid, the interface (and by extension, the designer) is. "The user is an idiot" is all too often a way to avoid looking a bad design in the face. This is the overarching theme of The Design Of Everyday Things [amazon.com]. It's like a self-help book for battered users. It's not your fault the computer beats you.

      But users are impatient, and rightfully so. Computers are there to make the user's life easier, not vice-versa. They have better things to do. If anyone kee

      • This can be solved with better tools [ext3cow.com]. I haven't used that particular one, but I've seen other variations on the concept. If you delete your important file, restore it.

        And, of course, do not under-estimate the value of using a revision control system for system administration...

      • Actually, in most well run userland systems, snapshots and restores are available for the users to do for themselves. I've always aliased rm and a few other commands as it's inevitable that I'm going to fuck up at some point. The downside of command-line power is having the power to do just what you describe. Every Yin has it's Yang.

        And if computers were here to make our lives easier and to give us so much free time then why does it seem like we give them more of our time with each passing year and where

        • And if computers were here to make our lives easier and to give us so much free time then why does it seem like we give them more of our time with each passing year

          BECAUSE THE INTERFACES SUCK! DOET has a chapter on computers that was written, IIRC, in the 80s laying out all the interface design mistakes they're making and why they're so hard to use. Reading it in 2008 is painful because we're still making those same mistakes.

          And where is our star trek future?

          iPhone. It's the closest thing to the ST:TNG PADD [memory-alpha.org] yet. I just noticed Donald Norman has a new book, The Invisible Computer [librarything.com] which probably addresses exactly that.

  • The trash can concept is such a useful idea, adopted by all the major desktop operating systems.

    It perhaps says something about geek culture that it is not yet built into major command line interfaces. I wish it was.

  • 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 hap