Today's Lesson Learned

There's an old saying that you hear when people complain that Unix is not as user-friendly as Windows or MacOS. It goes something like, "Unix IS user-friendly. It's just picky about its friends."

When you're running commands on the command line, you can't just go on autopilot; that way lies disaster. Unix doesn't really have a concept of "undo." You can usually recover from an error, but recovery requires that you have prepared for the error in advance. It can be very unforgiving.

For the past few days, I've been heavily involved in writing some tests for some of the features of our fax server product. I've been writing and rewriting code, changing, optimizing, creating. It's not been particularly difficult, just time-consuming--when I code, I usually follow the "get it working, then get it working right" school of thought. That is to say, I throw down the first thing I think of, make it work, and then figure out how it's wrong and how to fix it. That way, if there's a time crunch, we at least have working tests.

I'm also fundamentally lazy, so I try to have the tests do as many things as possible with as few commands as possible. I want to get all the work done at the beginning of the process, so that when crunch time comes, the tests can run and we can be sure that the core systems are working.

I've been taking notes, writing code, taking more notes, commenting my code, ripping pieces out and adding them back in. As I go along, I'm also finding a few bugs to write up, so it's been very fruitful. This is really what I enjoy about my job; I'd gladly put in 12-hour days doing this--it's like fighting the product to make it work, and I dig it.

One of the bugs I found has to do with an error that returns from a program that's supposed to delete one of the databases. It's not a real big deal; the databases are emptied out correctly, as far as I can tell--it's just that the program returns an error message, which means it's not running correctly. The solution for this is to delete the databases, all of which begin with the letters "pb," and recreate them. It's a simple process, involving the Unix "rm" command.

rm is the Unix remove command. It takes whatever file you give it and deletes it. That file is totally unretrievable. There is no undelete, there's no "Recycle Bin" or "Trash Can." The file is gone. It also takes the standard wild card characters, like "*" and "?" and so on. For example, to delete the six databases whose names all begin with "pb", you just type "rm pb*" and poof! They're gone.

The only problem comes when all the code you've written over the last three days also happens to be in files whose names begin with "pb," and you forget to change to the directory where the databases live. In that case, when you type "rm pb*," you delete three days worth of work.

I've done this before, and I should be a little bit more upset than I actually am. Three days of work is three days of work, after all, totally nuked. The lesson? Two, actually, always use source control (I like RCS because it's simple, but I'm going to look at perforce, and this is a good excuse), and always make sure you're in the right directory before you delete something.

Sure, you could use rm -i, which prompts you before deleting files, but where's the fun in that?