Along the lines of the hint on AppleScript and Calendar, I offer a probably not perfect additional example of integrating AppleScript with command line tools. It also demonstrates how to create a simple "droplet" script that you can drop one or more files or folders on. In this case it is a script I've dubbed Secure Erase that securely deletes anything dropped on it, with appropriate warning.

Needless to say, you should use this script with caution! It is mainly intended as an example, albeit a potentially useful one. Download either the script application or the text version or both. Note that you can drag the script application onto Script Editor to edit it, so the text version isn't strictly necessary.

The dirty work is handled with the command-line command "rm -rP" and AppleScripts's "do shell script" and "POSIX path" from the "Standard Additions" scripting addition are what do that.

You are free to use this script in any way you see fit as long as nothing in it is used in a for-profit endeavor. No warranties are expressed or implied - i.e. any damage caused by it is your own damn fault! Please DO suggest improvements.

Or at least it seems to work fine on my PowerBook and it has an HFS+ formatting. What would be the behavior of it NOT working? Would it still delete, but not do so securely? If that is the case, then I'll pull this, because that would be a very bad thing, to think something was securely deleted when it was not.

From reading Apple's developer page on HFS+, it looks to me like HFS+ is fixed-block, it's simply more efficient than HFS because there are more blocks available to spread over the whole disk (32-bits worth instead of 16):

HFS divides the total space on a volume into equal-sized pieces called allocation blocks. It uses 16-bit fields to identify a particular allocation block, so there must be less than 216 (65,536) allocation blocks on an HFS volume. The size of an allocation block is typically the smallest multiple of 512 such that there are less than 65,536 allocation blocks on the volume (i.e., the volume size divided by 65,535, rounded up to a multiple of 512). Any non-empty fork must occupy an integral number of allocation blocks. This means that the amount of space occupied by a fork is rounded up to a multiple of the allocation block size. As volumes (and therefore allocation blocks) get bigger, the amount of allocated but unused space increases.
HFS Plus uses 32-bit values to identify allocation blocks. This allows up to 2 32 (4,294,967,296) allocation blocks on a volume. More allocation blocks means a smaller allocation block size, especially on volumes of 1 GB or larger, which in turn means less average wasted space (the fraction of an allocation block at the end of a fork, where the entire allocation block is not actually used). It also means you can have more files, since the available space can be more finely distributed among a larger number of files. This change is especially beneficial if the volume contains a large number of small files.

However, that's just my reading of it. I don't claim to be an expert. They don't explicitly use the phrase, "fixed-block" anywhere that I can find. Anyone know for certain?

I wrote Trash X. When I added file shredding features to it, I relied on "rm -P" to handle the task. This was an embarassing mistake. In short, "rm -P" does not reliably shred files on HFS+ volumes. In my tests, it only worked on HFS+ in situations where the file to be shredded was larger than the available free space. In all other cases with HFS+, "rm -P" merely deleted the file without overwriting it. It is interesting to note however that "rm -P" takes longer to execute than just "rm". I believe that on HFS+ disks, "rm -P" essentially deletes the old file and creates a new file on each pass and writes its data sequence into it, but that is just conjecture on my part.

It upsets me to see "rm -P" so frequently touted as a CLI file shredding option. The reality is that most OS X users are using HFS+ partitions, and that is what Apple ships out of the box. For the majority of OS X users, "rm -P" is not a viable option.

And now the shameless plug. To my knowlege, Trash X is the only OS X GUI file shredder that offers support for files larger than 2 GB, and supports shredding freespace on disks.