that don't behave right when sending SIGINT. Examples are emacs'es
that die on Control-g or shellscript statements that sometimes are
executed and sometimes not, apparently not determined by the user's
that don't behave right when sending SIGINT. Examples are emacs'es
that die on Control-g or shellscript statements that sometimes are
executed and sometimes not, apparently not determined by the user's
</td></tr><tr><th valign=top align=left>Required knowledge: </th>
<td valign=top align=left>You have to know what it means to catch SIGINT or SIGQUIT and how
</td></tr><tr><th valign=top align=left>Required knowledge: </th>
<td valign=top align=left>You have to know what it means to catch SIGINT or SIGQUIT and how
<p>Now imagine the user hits C-c while a shellscript is executing its
first program. The following programs receive SIGINT: program1 and
<p>Now imagine the user hits C-c while a shellscript is executing its
first program. The following programs receive SIGINT: program1 and
<p>But what should the shell do? If we say that it is only the
innermost's programs business to react on SIGINT, the shell will do
<p>But what should the shell do? If we say that it is only the
innermost's programs business to react on SIGINT, the shell will do
<p>There are programs that want to exit on SIGINT, but they don't let
the system do the automatic exit, because they want to do some
<p>There are programs that want to exit on SIGINT, but they don't let
the system do the automatic exit, because they want to do some
and it will call the next program in the script.
<p>As a result, the user hits SIGINT and while one program exits, the
and it will call the next program in the script.
<p>As a result, the user hits SIGINT and while one program exits, the
special numeric value. People often assume this since the manuals for
shells often list some return value for exactly this. But this is just
a convention for your shell script. It does not work from one UNIX API
special numeric value. People often assume this since the manuals for
shells often list some return value for exactly this. But this is just
a convention for your shell script. It does not work from one UNIX API
<P>All that happens is that the shell sets the "$?" variable to a
special numeric value for the convenience of your script, because your
<P>All that happens is that the shell sets the "$?" variable to a
special numeric value for the convenience of your script, because your
<code>trap</code> command. Here, the same as for C programs apply. If
the intention of SIGINT is to end your program, you have to exit in a
way that the calling programs "sees" that you have been killed. If
<code>trap</code> command. Here, the same as for C programs apply. If
the intention of SIGINT is to end your program, you have to exit in a
way that the calling programs "sees" that you have been killed. If
SIGINT, i.e. to do cleanup work, you have to end the program by
killing yourself, not by calling exit.
SIGINT, i.e. to do cleanup work, you have to end the program by
killing yourself, not by calling exit.
bourne shell. Every language implementation that lets you catch SIGINT
should also give you the option to reset the signal and kill yourself.
bourne shell. Every language implementation that lets you catch SIGINT
should also give you the option to reset the signal and kill yourself.
expect your usual callers to depend on it, some unusual one will come
along. This proper exit status will be needed for WCE and will not
hurt when the calling shell uses IUE or WUE.
expect your usual callers to depend on it, some unusual one will come
along. This proper exit status will be needed for WCE and will not
hurt when the calling shell uses IUE or WUE.
<th>What happens when a shellscript called emacs, the user did not use
<code>C-c</code> and the script has additional commands in it?</th>
<th>What happens if a non-interactive child catches SIGINT?</th>
<th>What happens when a shellscript called emacs, the user did not use
<code>C-c</code> and the script has additional commands in it?</th>
<th>What happens if a non-interactive child catches SIGINT?</th>
<td>4.4BSD ash (ash), NetBSD, FreeBSD prior to 3.0/22.8</td>
<td>The editor session is lost and subsequent commands are not
executed.</td>
<td>4.4BSD ash (ash), NetBSD, FreeBSD prior to 3.0/22.8</td>
<td>The editor session is lost and subsequent commands are not
executed.</td>
signal (either it had the default handler for SIGINT or it killed
itself). </td>
<td>bash (Linux /bin/sh), most commercial /bin/sh, FreeBSD /bin/sh
signal (either it had the default handler for SIGINT or it killed
itself). </td>
<td>bash (Linux /bin/sh), most commercial /bin/sh, FreeBSD /bin/sh
<td>The editor continues as normal and subsequent commands are
executed. </td>
<td>The editor continues as normal and subsequent commands are
<td>The editor continues as normal and subsequent commands are
executed. </td>
<td>The editor continues as normal and subsequent commands are
the child did a normal exit (even if it received SIGINT, but catches
it), the script will continue. </td>
<td>The child must be implemented right, or the user will not be able
the child did a normal exit (even if it received SIGINT, but catches
it), the script will continue. </td>
<td>The child must be implemented right, or the user will not be able