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!!!!!!!
------------------------------------------------------
Remove file "foo.txt"?
[Yes] [No] [No, but I meant Yes] [Yes, but I meant No]
------------------------------------------------------
$ cat ~/bin/trash #!/bin/sh
mv --backup=numbered "$@" ~/.Trash/
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 carries on.
We had a long discussion about the whole idea, for example imagine a word processor with no save button. You open the document make some changes (all with undo) and the close the document. It never asks you to save the document it just does it, you can undo any event - even out of sequence and it just works.
A question should only come up by exception, for example "Please type: Yes really destroy my system" or some such on a really drastic rare command.
Re:Universal Undo
schwern on 2008-12-31T19:45:59
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 multiple "Undo" with "Redo". Mounting a version control system as a filesystem like Subversion and Clearcase can do.
Out of sequence undo... that gets into complicated patch algebra which is hard enough to implement in version control much less make it simple for a word processor.
The restraint there is more hardware than software. Universal undo can rapidly bloat out storage size.
Re:Universal Undo
ajt on 2008-12-31T22:30:21
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. Supposed to be very nice if a tad on the expensive side.
I'm sure that a complex universal undo can get really complex, I know it's something that DynaBase use to do to xml/html documents and it was ever so cool but made the system ever so slow when it had to rebuild a document from hundreds of changes...
Stupid designers
schwern on 2008-12-31T20:02:18
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. 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 keeps asks the same question over and over again and the answer is always the same, you're going to get impatient. Your alertness to the warning will rapidly drop off and you'll ignore it. The computer who cried wolf.
The most important aspect of a slip is how fast they happen and how fast you realize it. A split-second's lapse of judgment can make you push the wrong button, and just as fast you realize the mistake and want to undo it. If the solution to a one second lapse is to spend minutes, possibly hours, to restore from a probably days old backup which might not even have the file you just blew away, then your design is broken.
And who is the user going to ask to do that restore? And who are they going to grumble at when it's too old? Yep, the sysadmin. To just say "stupid user, restore from backup" just makes more work for you.
Computers making more work for humans defeats the point.
Re:Stupid designers
btilly on 2008-12-31T22:11:32
This can be solved with better tools. 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...
Re:Stupid designers
hfb on 2009-01-01T01:11:26
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 is our star trek future?
Re:Stupid designers
schwern on 2009-01-01T03:48:09
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 yet. I just noticed Donald Norman has a new book, The Invisible Computer 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.
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.
Re:A different approach
schwern on 2010-01-11T21:22:52
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.