<< August 1, 2007 | Home | August 3, 2007 >>

The Perils of Bash

I wanted to test some Grails 0.6 features, but for some reason the snapshot I downloaded was not upgrading my project properly. I made a copy of my project folder so I could revert to my original code easily. After a series of attempts to upgrade, interspaced with a few 'rm -r' and 'cp -R' commands, I accidentally selected a 'rm -r' command from the history and autocompleted my backup folder in addition to the source folder! I could feel the nerve impulse surge from my brain and down my arm, helpless to stop it reaching its destination - a finger twiched, the return key depressed, and my work evaporated.

The obvious lesson: don't goof around when tired at the end of the day without committing the work first. But now what? Happily for us programmers, we work with text. Using grep for file recovery didn't occur to me, but after a bit of Google inspiration I recovered most of my work. The command looks something like this:
sudo grep -a -B 2 -A 200 'class Lists' /dev/disk0 > classLists.txt
where B == show lines before, A == show lines after and 'class Lists' is the text to search for.

Once I had my work back, it was time to prevent this from ever happening again. A little while later I had a nice rm script on my machine that would move files to the trash. The script comes from http://www.cs.ecu.edu/~collins/rm/rm.html and some outdated instructions are at http://www.oreillynet.com/pub/h/334.

The commands I used to set things up look something like this:
cd ~
mkdir bin
cd bin
curl -o rm "http://www.cs.ecu.edu/~collins/rm.txt"
chmod 700 rm
echo 'alias rm=$HOME/bin/rm' >> ~/.bash_profile
source ~/.bash_profile
Now I am a little safer from myself. Hopefully the above instructions will be of use to others.