Respecting Unix signals

There is a certain class of program that decides it knows better than you about when you should be able to stop its operation. The most irritating way to do this is to catch ^C (and even ^\); such programs win a modest prize from me, usually awarded with 'kill -9'.

Yes, some operations are dangerous if interrupted half-way through and programs need to protect themselves against them. Short operations. It is very rare that a program needs to block signals for very long, and when it does it should take receiving a ^C as a sign that it needs to shut down as soon as it can.

(The Solaris patch process may block ^Cs for a long time, but that's more a sign that it's achingly slow and desperately needs to be fixed than anything else.)

The most irritating programs pay some attention to ^C, but not enough to actually exit or stop. They'll notice your desire for them to stop, but reinterpret it as, oh, 'interrupt the current network transfer' instead of actually stopping.

A tragic example of this is Red Hat's yum, which mostly ignores ^C (and entirely ignores ^\) during precisely the time it would be most useful: when doing a series of network fetches. Nothing vital is going on at this point and it can be quite time-consuming, yet rather than exiting on ^C yum takes it as a signal to abort the current transfer and start fetching the next file. Since you may be fetching 30 files, this is more than a bit annoying.

An example of handling this issue well is mpg123, the command line MP3 player. When it's playing multiple MP3 files, one ^C will stop the current file and skip to the next, but two ^C's in quick succession will cause it to just exit. (Some experimentation suggests that it does this by just exiting on ^Cs in the first few seconds of a file, which is simple enough to implement.)