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
-intention.
+intention.
</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
-processes are waiting for other processes (childs) they spawned.
+processes are waiting for other processes (children) they spawned.
</td></tr></table>
<p>Now imagine the user hits C-c while a shellscript is executing its
first program. The following programs receive SIGINT: program1 and
-also the shell executing the script. program1 exits.
+also the shell executing the script. program1 exits.
<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
calling program.
<p>Unless a program messes with signal handling, the system does this
-automatically.
+automatically.
<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
itself.
<p>Some programs don't do this. On SIGINT, they do cleanup and exit
-immediatly, but the calling shell isn't told about the non-normal exit
+immediately, but the calling shell isn't told about the non-normal exit
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
-program to another.
+program to another.
<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
-you don't catch SIGINT, this happend automatically, but of you catch
+you don't catch SIGINT, this happened automatically, but of you catch
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.
-<P>It is always desireable to exit the right way, even if you don't
+<P>It is always desirable to exit the right way, even if you don't
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>To behave properly, childs must do what?</th>
+<th>To behave properly, children must do what?</th>
</tr>
<tr valign=top align=left>
<td>IUE</td>
<td>The shell executing a script exits immediately if it receives
-SIGINT.</td>
+SIGINT.</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
-from 3.0/2.2.8.</td>
+from 3.0/2.2.8.</td>
<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
-to break shell scripts reliably.</td>
+to break shell scripts reliably.</td>
</tr>
</table>
projects / oweals / busybox.git / blobdiff