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