Shell signals...

Guy Harris guy at auspex.auspex.com
Tue Oct 16 12:09:20 AEST 1990


>If there is a newsgroup for shell inquiries, please flame me and with
>the newsgroup name...

There is - "comp.unix.shell" - but it turns out this isn't entirely a
shell inquiry....

>Does anyone have or know the complete list of shell signals(csh/sh/ksh)?
>
>I have a program that traps the ususal ones, but my UNIX guru ran it and then
>did something that emitted a signal that I didn't find(I used 1 2 15).

"Shell signals" are just ordiinary UNIX signals; the signals it lets you
trap are just the ordinary UNIX signals (although some, but not all,
shells won't let you catch signal 11).

Not all UNIX systems use the same signal numbers for the same signals. 
The signals up to 15 are the same on most if not all UNIX systems;
others differ more.  Ultimately, the shell will let you catch signals by
name rather than by number, so you can write more portable shell scripts
(I think it'll also turn the signal numbers, in effect, into names, so
signal 1 will be SIGHUP even if SIGHUP isn't 1 on the system).

Some signals *CANNOT* be caught, no matter how nicely you ask; signal
SIGKILL, normally signal 9, cannot be caught (this allows you to kill
off a process that has protected itself from all other signals, and is a
useful escape hatch).

The signals you caught are probably the only ones you *should* catch. 
Other signals either:

1) are caused by bugs in the shell, and shouldn't be caught;

2) can't be caught, such as SIGKILL;

3) have a default action of "ignore", and as such aren't worth catching;

4) are used for other purposes, e.g. stopping a job on a system with job
   control, and should only be caught if you have some good reason not
   to let a job running your shell script be caught.



More information about the Comp.unix mailing list