If at all possible, avoid signals. They are tricky to use correctly, and signal-handling code is perhaps the most difficult to debug. Despite these warnings, there are situations in which signals are the only solution. In this chapter, I will describe the reasons why you may have to deal with signals and how to handle them. I will also present related details of the
Signals are software interrupts. They can be generated for a variety of reasons such as the pressing of certain keystrokes. In cooked mode, pressing control-C usually generates an interrupt signal in the foreground process. Processes can also generate signals in other processes—or even in themselves. This is commonly referred to as sending a signal. Finally, the operating system can generate signals for a number of reasons, such as if a power failure is imminent and the system is about to halt. For more in-depth information on signals, read your local man page on
Specific signals are commonly referred to in several ways. For example, signal number 9 is usually written as
SIGKILL in C programs. However, many utilities (e.g.,
kill) only accept
KILL (without the
SIG prefix). Expect accepts all three forms (
SIGKILL). For clarity in this book, I like to use the C-style although I will give examples of why the other two forms are occasionally useful.
The exact list of signals varies from one system to another but modern systems include those shown in ...