Just a helpful tip to would-be script writers out there: It is advisable to examine your script before you run it. I learned this lesson the hard way recently.

Before the upgrade to v2.22, the Gnome desktop environment kept each user’s “trash can” in the folder ~/.Trash. Performing a “soft” delete of a file merely moved the file to the trash can, where it would await permanent deletion.

Being a security-conscious person, I made a habit of shredding my deleted files when I emptied the trash. Since there exists no built-in feature to do so, I wrote my own simple script to do it for me, as follows.

#!/bin/bash

# Empty the "trash"
cd ~/.Trash
shred -n 3 *
sync
rm -rf *

It performed its elementary task perfectly.

However, when Gnome upgraded to v2.22, the location of the trash can changed (for better compliance with the FreeDesktop.org standards) to ~/.local/share/Trash. In this folder exist two folders, “files” and “info”, which contain the actual deleted files and info for their undeletion, respectively.

So I had to upgrade my script to shred the new trash can. At the same time I decided to add an option to empty the trash without shredding the files because sometimes I would have large non-sensitive files (such as Linux distro ISOs) that I didn’t care to spend time shredding. So I rewrote my script in less than a minute to this:

#!/bin/bash

# Empty the "trash"
if [ "$1" = "shred" ]; then
	cd ~/.local/share/Trash
	shred -n 3 files info
	sync
fi
rm -rf files info
mkdir files info
chown b-con:users files info

Since I was working on various other school/personal projects, I made the changes without thinking too much about it and quickly moved on to other tasks.

If you have any experience with programing, a quick glance through that revised script should raise a serious red flag.

That’s right, my script only changed into the trash directory if I was performing the shred operation. If I was not performing the shred operation, it did not change directories and merely deleted “files” and “info” from my current directory. I had placed one line of code just one line too low.

I suppose it goes without saying that in my home directory I keep a folder called “files”. This is where I store dozens of miscellaneous files, such as half-finished writings for this website. The first time I executed the script without the “shred” optoin while in my home directory, which was that very day, the contents of my “files” folder disappeared.

When I noticed what had happened several days later, I nearly had a heart attack. I spend a long time looking through various logs and my bash history, trying to determine what had happened. I was mad that something had the audacity to touch files in my home folder. I was ready to strace every binary on my system. However, seeing the presence of the new “info” folder eventually sparked my memory and I realized what had happened. Needless to say, I felt more than just a tad embarrassed.

I recovered just about everything from a lucky three-week-old backup I had made by chance, so all ended well. But still, that’s one lesson I’ll not soon forget: Always proof-read your bloody code, even just briefly.