Go to the first, previous, next, last section, table of contents.

Signals and Traps

Unix provides a mechanism known as signals to inform a process of some event which it may be interested in and wish to deal with or respond to. The shell also generates certain events that a shell programmer may wish to have the shell repond to. Both of these types of events are handled in the shell by a mechanism known as Traps.

This mechanism allows the association of a piece of shell code with each signal and shell event. At the first convenient moment after an event occurs, the shell suspends what ever it was doing and executes the given piece of code. On termination of the commands in the code, the shell continues where it left off.

break or continue builtin commands run by the code in a trap can affect any complex command that was running when the trap occurred.

The trap code only has access to global varaibles, not to any variables that were local to the code executing at the time of the trap.

All traps have uppercase names, defined ether by the system (for signals) or by the shell (for events). Traps can also be refered to by numbers - positive system defined numbers for signals and negative (or zero) numbers for events. Except for the EXIT event, which is guarenteed to be zero, the numbers for the other events are not documented and may well change between releases of the shell.

The events generated by the shell are:

`EXIT'

This event is generated just before the shell exits, either due to reaching end of file on its input, or from executing the exit command.

`ERR'

This event should be generated when an error occurs, but isn't!

`PARSE'

This event is generated just before the shell attempts to read and parse a new command for its primary input (standard input or script file). This is useful for doing something before each prompt in interactive mode. The default action for this event is to check for mail in a file named by the MAIL variable.

`EXEC'

This event is generated after a command has been successfully read and parsed from primary input, but before it is executed.

`NOTIFY'

This event is generated whenever a job changes status in an interesting way (As defined by the NOTIFY variable. See Job Control).

`SYMLINK'

This event is generated whenever the shell changes directory through a symbolic link. As checking for symbolic links is a bit expensive, the check is only done if some command has been associated with this trap.

If no command is associated with a particular shell event, it is simply ignored. If no command is associated with a particular signal, some default handling is applied. For all signals not mentioned below, the default handling is that imposed by the system, which usually involves the shell process being terminated.

`INT'

An interrupt works much like the break builtin when given a very large argument. Any running command is gracefully terminated. If the shell is interactive it prompts for another command, otherwise it exits (triggering the EXIT trap).

`QUIT'

The QUIT signal is completely ignored.

`TERM'

The terminate signal is ignored too, though this should change;

`ALRM'

The alarm signal is also ignored.

`CLD / CHLD'

I should check on this.

It is possible to cause any signal to be completely ignored by making the shell code associated with it be the empty string. This also causes all child processes of the shell to ignore the signal.

Go to the first, previous, next, last section, table of contents.