Compiling devkitPPC on my Wii was taking forever, and from my couch I can't really see the screen to see how it's going. So I hacked together a simple script to control the blue disc drive LED:

#installed as /usr/local/bin/discled
echo 250 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio250/direction
echo $1 > /sys/class/gpio/gpio250/value
echo 250 > /sys/class/gpio/unexport

And a .bashrc hack to use it:

# turn disc LED off before displaying a prompt, so that
# we know the command has finished
PROMPT_COMMAND='discled 0 > /dev/null 2>&1'

# turn it on before executing a command
trap 'discled 1 > /dev/null 2>&1' DEBUG

Now, whenever you run a command in bash, the LED will turn on, and turn off again when the command finishes. That way you can easily look over to see if the LED is still on, to check if your long-running compile is finished yet.

Of course this is a dirty hack, so it's far from perfect. The LED will be on the entire time you're working in nano, will turn on/off when you're working in other terminals while one is busy, won't inform you if the batch job is paused waiting for user input, etc. A smarter program might run as a daemon, turning the LED on whenever CPU/disk/network activity is high enough or blinking it whenever a character is written to the terminal, under the assumption that if the job is paused or finished, the system is going to be mostly idle. But that's another hack for another day.

One amusing side effect is that you won't be able to simply turn the LED on using the script, because bash will immediately turn it off again. If you want to do that (say because you executed a command in one terminal while another was busy, and want to turn it back on to monitor that job), you can do:

(sleep 1; discled 1)&

So that after bash shows the prompt (and turns the LED off), it'll turn back on a second later.

Sent from my toaster.