I did this with a DELETE SQL WHERE clause, trying to isolate a set of records, instead selecting all records, in an effort to test a production installation, at 3am (YES) and had to buy 3 db admins lunch the following day because they came in to restore multiple customer tables. The DELETE's were triggered across numerous tables and platforms (AS400 and SQL Server). The walk of shame to tell my director was not my most shining moment. I'd like to go back in time and slap myself just moments before. Running commands on live production data. Silly programmer.
At least with MySQL's tools, thanks to ssh's happiness to work as a pipe, it's very easy to clone a database locally for fucking about when you're trying to do something like this:
ssh remotehost.example.com mysqldump -udbuser proddatabase | mysql -uroot testdatabase
(n.b. the mysqldump options that may lock your production tables during the dump.)
The above line of code successfully fixed a bug I'd been trying to find for weeks in source code in the same directory. When I rewrote it from scratch, the bug was gone.
I find rm -i to be unusable because it is so annoying when you are deleting more than a couple files. It would be nice if rm -I (notice the capital) would first determine all of the files to remove, print them out and then ask if you want to delete all of those files. Instead it just says "rm: remove all arguments?" which is clearly much less annoying than having to type y for every file, but it is also mostly useless.
I usually don't alias the command itself; that's bad form. It limits what you can do and screws you when you are using an environment without your alias when you forget it. Live and learn.
Exactly -- I was benchmarking a disk that was having a performance problem. and I did something like "dd if=/dev/zero of=/dev/sda" instead of "of=/testfile".