* Shellology:: A zoology of shells
* Here-Documents:: Quirks and tricks
* File Descriptors:: FDs and redirections
-* Signal handling:: Shells, signals, and headaches
+* Signal Handling:: Shells, signals, and headaches
* File System Conventions:: File names
* Shell Pattern Matching:: Pattern matching
* Shell Substitutions:: Variable and command expansions
* Shellology:: A zoology of shells
* Here-Documents:: Quirks and tricks
* File Descriptors:: FDs and redirections
-* Signal handling:: Shells, signals, and headaches
+* Signal Handling:: Shells, signals, and headaches
* File System Conventions:: File names
* Shell Pattern Matching:: Pattern matching
* Shell Substitutions:: Variable and command expansions
@end example
@c <http://lists.gnu.org/archive/html/bug-autoconf/2011-09/msg00004.html>
-@node Signal handling
-@section Signal handling
+@node Signal Handling
+@section Signal Handling
@cindex Signal handling in the shell
@cindex Signals, shells and
headaches. This is worsened by the fact that various different, mutually
incompatible approaches are possible in this area, each with its
distinctive merits and demerits. A detailed description of these possible
-approaches, as well as of their the pros and cons, can be found in
+approaches, as well as of their pros and cons, can be found in
@uref{http://www.cons.org/cracauer/sigint.html, this article}.
Solaris 10 @command{/bin/sh} automatically traps most signals by default;
This gets even worse if one is using the POSIX `wait' interface to get
details about the shell process terminations: it will result in the shell
-exiting normally, rather than by receiving a signal.
+having exited normally, rather than by receiving a signal.
@example
$ @kbd{cat > foo.c <<'END'}
Exited normally: no
@end example
-Some shells seem to handle @code{SIGQUIT} specially: they ignore it even
+Various shells seem to handle @code{SIGQUIT} specially: they ignore it even
if it is not blocked, and even if the shell is not running interactively
(in fact, even if the shell has no attached tty); among these shells
are at least Bash (from version 2 onwards), Zsh 4.3.12, Solaris 10
of @code{SIGQUIT}; among these shells are at least @code{pdksh} 5.2.14,
Solaris 10 and NetBSD 5.1 @code{/bin/sh}, and the Almquist Shell 0.5.5.1.
+@c See: <http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2009-February/004121.html>
Some shells (especially Korn shells and derivatives) might try to
propagate to themselves a signal that has killed a child process; this is
not a bug, but a conscious design choice (although its overall value might
128 + 2). In any case, if there is an active trap associated with
@code{SIGINT}, those shells will correctly execute it.
+@c See: <http://www.austingroupbugs.net/view.php?id=51>
Some Korn shells, when a child process die due receiving a signal with
signal number @var{n}, can leave in @samp{$?} an exit status of
256+@var{n} instead of the more common 128+@var{n}. Observe the