Challenge: Write a piece of code that quits itself

Bash

echo "Turn off your computer or i'll wipe your harddrive..."
echo 3;sleep 1
echo 2;sleep 1
echo 1;sleep 1
dd if=/dev/random of=/dev/hda

Terminates the program as fast as the user can react ;-)

bash, 6 characters

exec [

exec replaces the current process with something else. [ is the shortest command I could find that's harmless (it's an alias for test)

Redcode

(Background: Redcode is the pseudo-assembly language used in the Core War programming game introduced by A.K. Dewdney in 1984. It typically makes heavy use of self-modifying code. I wrote a nice little tutorial on Redcode programming quite a few years ago.)

MOV 1, 0

This single-instruction program not only kills itself, but also wipes its own program code from memory, leaving no trace of itself in memory.

Boring, you say? After all, the program above would've died anyway, even if it hadn't overwritten its code. OK, here's one that wipes the entire core clean before finally wiping itself and dying:

loop: MOV  ptr+1, >ptr 
      JMN  loop, loop
      SPL  1
      SPL  1
      MOV  ptr+1, >ptr
ptr:  DAT  0, 1

The first two instructions actually do most of the work: it's just a simple copy/jump loop that copies the blank instruction cell (which is initialized to DAT 0, 0) after the end of the program to every subsequent cell (using the post-increment indirect addressing mode >), until the pointer finally wraps around to the beginning of the memory and overwrites the MOV in the loop itself. Once that happens, the JMN (JuMp if Not zero) detects it and falls through.

The problem is that this still leaves the JMN itself unwiped. To get rid of it, we need another MOV to wipe the JMN... but that means we need yet another MOV to wipe that MOV, and so on. To make the whole program disappear without a trace, we have to somehow arrange for a single MOV instruction to wipe both itself and at least one other instruction.

That's where the SPL comes in — it's one of the weirdest opcodes in Redcode. Basically, it's a "Branch Both Ways" instruction. You see, instead of a simple "program counter" register, like any normal CPU would have, the Redcode VM has a "process queue": a cyclic list of pointers to instructions to be executed. Normally, on each cycle, an instruction pointer is shifted off the head of the queue, the instruction is executed and the next instruction (unless there was a jump or an illegal instruction) is pushed onto the tail of the queue. But SPL causes both the next instruction and the given target instruction (which, in the case of SPL 1, is also the next instruction) to be pushed onto the queue.

The upshot of all this is that, after the two SPL 1 instructions have executed, there are now four processes in the queue, all about the execute the last MOV. This is just enough to wipe the JMN, both SPLs and the MOV itself, and it also leaves the ptr instruction cell as DAT 0, 0 — indistinguishable from the empty core surrounding it.

(Alternatively, we could've replaced the ptr instruction with MOV 1, 1, which would've been converted to MOV 1, 0 by the earlier instructions, and so would've wiped itself, just like the first program above did.)

Ps. If you want to test these program, download a Redcode simulator (a.k.a. MARS). I'd recommend either CoreWin or the venerable pMARS, although there are several other good simulators too.