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
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
(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.