Contents of /tags/mkinitrd-6_1_4/busybox/docs/sigint.htm
Parent Directory | Revision Log
Revision 896 -
(show annotations)
(download)
(as text)
Wed Aug 5 16:25:39 2009 UTC (15 years, 1 month ago) by niro
File MIME type: text/html
File size: 25528 byte(s)
Wed Aug 5 16:25:39 2009 UTC (15 years, 1 month ago) by niro
File MIME type: text/html
File size: 25528 byte(s)
tagged 'mkinitrd-6_1_4'
1 | <HTML> |
2 | <HEAD> |
3 | <link rel="SHORTCUT ICON" href="http://www.cons.org/favicon.ico"> |
4 | <TITLE>Proper handling of SIGINT/SIGQUIT [http://www.cons.org/cracauer/sigint.html]</TITLE> |
5 | <!-- Created by: GNU m4 using $Revision: 1.20 $ of crawww.m4lib on 11-Feb-2005 --> |
6 | <BODY BGCOLOR="#fff8e1"> |
7 | <CENTER><H2>Proper handling of SIGINT/SIGQUIT</H2></CENTER> |
8 | <img src=linie.png width="100%" alt=" "> |
9 | <P> |
10 | |
11 | <table border=1 cellpadding=4> |
12 | <tr><th valign=top align=left>Abstract: </th> |
13 | <td valign=top align=left> |
14 | In UNIX terminal sessions, you usually have a key like |
15 | <code>C-c</code> (Control-C) to immediately end whatever program you |
16 | have running in the foreground. This should work even when the program |
17 | you called has called other programs in turn. Everything should be |
18 | aborted, giving you your command prompt back, no matter how deep the |
19 | call stack is. |
20 | |
21 | <p>Basically, it's trivial. But the existence of interactive |
22 | applications that use SIGINT and/or SIGQUIT for other purposes than a |
23 | complete immediate abort make matters complicated, and - as was to |
24 | expect - left us with several ways to solve the problems. Of course, |
25 | existing shells and applications follow different ways. |
26 | |
27 | <P>This Web pages outlines different ways to solve the problem and |
28 | argues that only one of them can do everything right, although it |
29 | means that we have to fix some existing software. |
30 | |
31 | |
32 | |
33 | </td></tr><tr><th valign=top align=left>Intended audience: </th> |
34 | <td valign=top align=left>Programmers who implement programs that catch SIGINT/SIGQUIT. |
35 | <BR>Programmers who implements shells or shell-like programs that |
36 | execute batches of programs. |
37 | |
38 | <p>Users who have problems problems getting rid of runaway shell |
39 | scripts using <code>Control-C</code>. Or have interactive applications |
40 | that don't behave right when sending SIGINT. Examples are emacs'es |
41 | that die on Control-g or shellscript statements that sometimes are |
42 | executed and sometimes not, apparently not determined by the user's |
43 | intention. |
44 | |
45 | |
46 | </td></tr><tr><th valign=top align=left>Required knowledge: </th> |
47 | <td valign=top align=left>You have to know what it means to catch SIGINT or SIGQUIT and how |
48 | processes are waiting for other processes (childs) they spawned. |
49 | |
50 | |
51 | </td></tr></table> |
52 | <img src=linie.png width="100%" alt=" "> |
53 | |
54 | |
55 | <H3>Basic concepts</H3> |
56 | |
57 | What technically happens when you press Control-C is that all programs |
58 | running in the foreground in your current terminal (or virtual |
59 | terminal) get the signal SIGINT sent. |
60 | |
61 | <p>You may change the key that triggers the signal using |
62 | <code>stty</code> and running programs may remap the SIGINT-sending |
63 | key at any time they like, without your intervention and without |
64 | asking you first. |
65 | |
66 | <p>The usual reaction of a running program to SIGINT is to exit. |
67 | However, not all program do an exit on SIGINT, programs are free to |
68 | use the signal for other actions or to ignore it at all. |
69 | |
70 | <p>All programs running in the foreground receive the signal. This may |
71 | be a nested "stack" of programs: You started a program that started |
72 | another and the outer is waiting for the inner to exit. This nesting |
73 | may be arbitrarily deep. |
74 | |
75 | <p>The innermost program is the one that decides what to do on SIGINT. |
76 | It may exit, do something else or do nothing. Still, when the user hit |
77 | SIGINT, all the outer programs are awaken, get the signal and may |
78 | react on it. |
79 | |
80 | <H3>What we try to achieve</H3> |
81 | |
82 | The problem is with shell scripts (or similar programs that call |
83 | several subprograms one after another). |
84 | |
85 | <p>Let us consider the most basic script: |
86 | <PRE> |
87 | #! /bin/sh |
88 | program1 |
89 | program2 |
90 | </PRE> |
91 | and the usual run looks like this: |
92 | <PRE> |
93 | $ sh myscript |
94 | [output of program1] |
95 | [output of program2] |
96 | $ |
97 | </PRE> |
98 | |
99 | <p>Let us assume that both programs do nothing special on SIGINT, they |
100 | just exit. |
101 | |
102 | <p>Now imagine the user hits C-c while a shellscript is executing its |
103 | first program. The following programs receive SIGINT: program1 and |
104 | also the shell executing the script. program1 exits. |
105 | |
106 | <p>But what should the shell do? If we say that it is only the |
107 | innermost's programs business to react on SIGINT, the shell will do |
108 | nothing special (not exit) and it will continue the execution of the |
109 | script and run program2. But this is wrong: The user's intention in |
110 | hitting C-c is to abort the whole script, to get his prompt back. If |
111 | he hits C-c while the first program is running, he does not want |
112 | program2 to be even started. |
113 | |
114 | <p>here is what would happen if the shell doesn't do anything: |
115 | <PRE> |
116 | $ sh myscript |
117 | [first half of program1's output] |
118 | C-c [users presses C-c] |
119 | [second half of program1's output will not be displayed] |
120 | [output of program2 will appear] |
121 | </PRE> |
122 | |
123 | |
124 | <p>Consider a more annoying example: |
125 | <pre> |
126 | #! /bin/sh |
127 | # let's assume there are 300 *.dat files |
128 | for file in *.dat ; do |
129 | dat2ascii $dat |
130 | done |
131 | </pre> |
132 | |
133 | If your shell wouldn't end if the user hits <code>C-c</code>, |
134 | <code>C-c</code> would just end <strong>one</strong> dat2ascii run and |
135 | the script would continue. Thus, you had to hit <code>C-c</code> up to |
136 | 300 times to end this script. |
137 | |
138 | <H3>Alternatives to do so</H3> |
139 | |
140 | <p>There are several ways to handle abortion of shell scripts when |
141 | SIGINT is received while a foreground child runs: |
142 | |
143 | <menu> |
144 | |
145 | <li>As just outlined, the shellscript may just continue, ignoring the |
146 | fact that the user hit <code>C-c</code>. That way, your shellscript - |
147 | including any loops - would continue and you had no chance of aborting |
148 | it except using the kill command after finding out the outermost |
149 | shell's PID. This "solution" will not be discussed further, as it is |
150 | obviously not desirable. |
151 | |
152 | <p><li>The shell itself exits immediately when it receives SIGINT. Not |
153 | only the program called will exit, but the calling (the |
154 | script-executing) shell. The first variant is to exit the shell (and |
155 | therefore discontinuing execution of the script) immediately, while |
156 | the background program may still be executing (remember that although |
157 | the shell is just waiting for the called program to exit, it is woken |
158 | up and may act). I will call the way of doing things the "IUE" (for |
159 | "immediate unconditional exit") for the rest of this document. |
160 | |
161 | <p><li>As a variant of the former, when the shell receives SIGINT |
162 | while it is waiting for a child to exit, the shell does not exit |
163 | immediately. but it remembers the fact that a SIGINT happened. After |
164 | the called program exits and the shell's wait ends, the shell will |
165 | exit itself and hence discontinue the script. I will call the way of |
166 | doing things the "WUE" (for "wait and unconditional exit") for the |
167 | rest of this document. |
168 | |
169 | <p><li>There is also a way that the calling shell can tell whether the |
170 | called program exited on SIGINT and if it ignored SIGINT (or used it |
171 | for other purposes). As in the <sl>WUE</sl> way, the shell waits for |
172 | the child to complete. It figures whether the program was ended on |
173 | SIGINT and if so, it discontinue the script. If the program did any |
174 | other exit, the script will be continued. I will call the way of doing |
175 | things the "WCE" (for "wait and cooperative exit") for the rest of |
176 | this document. |
177 | |
178 | </menu> |
179 | |
180 | <H3>The problem</H3> |
181 | |
182 | On first sight, all three solutions (IUE, WUE and WCE) all seem to do |
183 | what we want: If C-c is hit while the first program of the shell |
184 | script runs, the script is discontinued. The user gets his prompt back |
185 | immediately. So what are the difference between these way of handling |
186 | SIGINT? |
187 | |
188 | <p>There are programs that use the signal SIGINT for other purposes |
189 | than exiting. They use it as a normal keystroke. The user is expected |
190 | to use the key that sends SIGINT during a perfectly normal program |
191 | run. As a result, the user sends SIGINT in situations where he/she |
192 | does not want the program or the script to end. |
193 | |
194 | <p>The primary example is the emacs editor: C-g does what ESC does in |
195 | other applications: It cancels a partially executed or prepared |
196 | operation. Technically, emacs remaps the key that sends SIGINT from |
197 | C-c to C-g and catches SIGINT. |
198 | |
199 | <p>Remember that the SIGINT is sent to all programs running in the |
200 | foreground. If emacs is executing from a shell script, both emacs and |
201 | the shell get SIGINT. emacs is the program that decides what to do: |
202 | Exit on SIGINT or not. emacs decides not to exit. The problem arises |
203 | when the shell draws its own conclusions from receiving SIGINT without |
204 | consulting emacs for its opinion. |
205 | |
206 | <p>Consider this script: |
207 | <PRE> |
208 | #! /bin/sh |
209 | emacs /tmp/foo |
210 | cp /tmp/foo /home/user/mail/sent |
211 | </PRE> |
212 | |
213 | <p>If C-g is used in emacs, both the shell and emacs will received |
214 | SIGINT. Emacs will not exit, the user used C-g as a normal editing |
215 | keystroke, he/she does not want the script to be aborted on C-g. |
216 | |
217 | <p>The central problem is that the second command (cp) may |
218 | unintentionally be killed when the shell draws its own conclusion |
219 | about the user's intention. The innermost program is the only one to |
220 | judge. |
221 | |
222 | <H3>One more example</H3> |
223 | |
224 | <p>Imagine a mail session using a curses mailer in a tty. You called |
225 | your mailer and started to compose a message. Your mailer calls emacs. |
226 | <code>C-g</code> is a normal editing key in emacs. Technically it |
227 | sends SIGINT (it was <code>C-c</code>, but emacs remapped the key) to |
228 | <menu> |
229 | <li>emacs |
230 | <li>the shell between your mailer and emacs, the one from your mailers |
231 | system("emacs /tmp/bla.44") command |
232 | <li>the mailer itself |
233 | <li>possibly another shell if your mailer was called by a shell script |
234 | or from another application using system(3) |
235 | <li>your interactive shell (which ignores it since it is interactive |
236 | and hence is not relevant to this discussion) |
237 | </menu> |
238 | |
239 | <p>If everyone just exits on SIGINT, you will be left with nothing but |
240 | your login shell, without asking. |
241 | |
242 | <p>But for sure you don't want to be dropped out of your editor and |
243 | out of your mailer back to the commandline, having your edited data |
244 | and mailer status deleted. |
245 | |
246 | <p>Understand the difference: While <code>C-g</code> is used an a kind |
247 | of abort key in emacs, it isn't the major "abort everything" key. When |
248 | you use <code>C-g</code> in emacs, you want to end some internal emacs |
249 | command. You don't want your whole emacs and mailer session to end. |
250 | |
251 | <p>So, if the shell exits immediately if the user sends SIGINT (the |
252 | second of the four ways shown above), the parent of emacs would die, |
253 | leaving emacs without the controlling tty. The user will lose it's |
254 | editing session immediately and unrecoverable. If the "main" shell of |
255 | the operating system defaults to this behavior, every editor session |
256 | that is spawned from a mailer or such will break (because it is |
257 | usually executed by system(3), which calls /bin/sh). This was the case |
258 | in FreeBSD before I and Bruce Evans changed it in 1998. |
259 | |
260 | <p>If the shell recognized that SIGINT was sent and exits after the |
261 | current foreground process exited (the third way of the four), the |
262 | editor session will not be disturbed, but things will still not work |
263 | right. |
264 | |
265 | <H3>A further look at the alternatives</H3> |
266 | |
267 | <p>Still considering this script to examine the shell's actions in the |
268 | IUE, WUE and ICE way of handling SIGINT: |
269 | <PRE> |
270 | #! /bin/sh |
271 | emacs /tmp/foo |
272 | cp /tmp/foo /home/user/mail/sent |
273 | </PRE> |
274 | |
275 | <p>The IUE ("immediate unconditional exit") way does not work at all: |
276 | emacs wants to survive the SIGINT (it's a normal editing key for |
277 | emacs), but its parent shell unconditionally thinks "We received |
278 | SIGINT. Abort everything. Now.". The shell will exit even before emacs |
279 | exits. But this will leave emacs in an unusable state, since the death |
280 | of its calling shell will leave it without required resources (file |
281 | descriptors). This way does not work at all for shellscripts that call |
282 | programs that use SIGINT for other purposes than immediate exit. Even |
283 | for programs that exit on SIGINT, but want to do some cleanup between |
284 | the signal and the exit, may fail before they complete their cleanup. |
285 | |
286 | <p>It should be noted that this way has one advantage: If a child |
287 | blocks SIGINT and does not exit at all, this way will get control back |
288 | to the user's terminal. Since such programs should be banned from your |
289 | system anyway, I don't think that weighs against the disadvantages. |
290 | |
291 | <p>WUE ("wait and unconditional exit") is a little more clever: If C-g |
292 | was used in emacs, the shell will get SIGINT. It will not immediately |
293 | exit, but remember the fact that a SIGINT happened. When emacs ends |
294 | (maybe a long time after the SIGINT), it will say "Ok, a SIGINT |
295 | happened sometime while the child was executing, the user wants the |
296 | script to be discontinued". It will then exit. The cp will not be |
297 | executed. But that's bad. The "cp" will be executed when the emacs |
298 | session ended without the C-g key ever used, but it will not be |
299 | executed when the user used C-g at least one time. That is clearly not |
300 | desired. Since C-g is a normal editing key in emacs, the user expects |
301 | the rest of the script to behave identically no matter what keys he |
302 | used. |
303 | |
304 | <p>As a result, the "WUE" way is better than the "IUE" way in that it |
305 | does not break SIGINT-using programs completely. The emacs session |
306 | will end undisturbed. But it still does not support scripts where |
307 | other actions should be performed after a program that use SIGINT for |
308 | non-exit purposes. Since the behavior is basically undeterminable for |
309 | the user, this can lead to nasty surprises. |
310 | |
311 | <p>The "WCE" way fixes this by "asking" the called program whether it |
312 | exited on SIGINT or not. While emacs receives SIGINT, it does not exit |
313 | on it and a calling shell waiting for its exit will not be told that |
314 | it exited on SIGINT. (Although it receives SIGINT at some point in |
315 | time, the system does not enforce that emacs will exit with |
316 | "I-exited-on-SIGINT" status. This is under emacs' control, see below). |
317 | |
318 | <p>this still work for the normal script without SIGINT-using |
319 | programs:</p> |
320 | <PRE> |
321 | #! /bin/sh |
322 | program1 |
323 | program2 |
324 | </PRE> |
325 | |
326 | Unless program1 and program2 mess around with signal handling, the |
327 | system will tell the calling shell whether the programs exited |
328 | normally or as a result of SIGINT. |
329 | |
330 | <p>The "WCE" way then has an easy way to things right: When one called |
331 | program exited with "I-exited-on-SIGINT" status, it will discontinue |
332 | the script after this program. If the program ends without this |
333 | status, the next command in the script is started. |
334 | |
335 | <p>It is important to understand that a shell in "WCE" modus does not |
336 | need to listen to the SIGINT signal at all. Both in the |
337 | "emacs-then-cp" script and in the "several-normal-programs" script, it |
338 | will be woken up and receive SIGINT when the user hits the |
339 | corresponding key. But the shell does not need to react on this event |
340 | and it doesn't need to remember the event of any SIGINT, either. |
341 | Telling whether the user wants to end a script is done by asking that |
342 | program that has to decide, that program that interprets keystrokes |
343 | from the user, the innermost program. |
344 | |
345 | <H3>So everything is well with WCE?</H3> |
346 | |
347 | Well, almost. |
348 | |
349 | <p>The problem with the "WCE" modus is that there are broken programs |
350 | that do not properly communicate the required information up to the |
351 | calling program. |
352 | |
353 | <p>Unless a program messes with signal handling, the system does this |
354 | automatically. |
355 | |
356 | <p>There are programs that want to exit on SIGINT, but they don't let |
357 | the system do the automatic exit, because they want to do some |
358 | cleanup. To do so, they catch SIGINT, do the cleanup and then exit by |
359 | themselves. |
360 | |
361 | <p>And here is where the problem arises: Once they catch the signal, |
362 | the system will no longer communicate the "I-exited-on-SIGINT" status |
363 | to the calling program automatically. Even if the program exit |
364 | immediately in the signal handler of SIGINT. Once it catches the |
365 | signal, it has to take care of communicating the signal status |
366 | itself. |
367 | |
368 | <p>Some programs don't do this. On SIGINT, they do cleanup and exit |
369 | immediatly, but the calling shell isn't told about the non-normal exit |
370 | and it will call the next program in the script. |
371 | |
372 | <p>As a result, the user hits SIGINT and while one program exits, the |
373 | shellscript continues. To him/her it looks like the shell fails to |
374 | obey to his abortion command. |
375 | |
376 | <p>Both IUE or WUE shell would not have this problem, since they |
377 | discontinue the script on their own. But as I said, they don't support |
378 | programs using SIGINT for non-exiting purposes, no matter whether |
379 | these programs properly communicate their signal status to the calling |
380 | shell or not. |
381 | |
382 | <p>Since some shell in wide use implement the WUE way (and some even |
383 | IUE), there is a considerable number of broken programs out there that |
384 | break WCE shells. The programmers just don't recognize it if their |
385 | shell isn't WCE. |
386 | |
387 | <H3>How to be a proper program</H3> |
388 | |
389 | <p>(Short note in advance: What you need to achieve is that |
390 | WIFSIGNALED(status) is true in the calling program and that |
391 | WTERMSIG(status) returns SIGINT.) |
392 | |
393 | <p>If you don't catch SIGINT, the system automatically does the right |
394 | thing for you: Your program exits and the calling program gets the |
395 | right "I-exited-on-SIGINT" status after waiting for your exit. |
396 | |
397 | <p>But once you catch SIGINT, you have to act. |
398 | |
399 | <p>Decide whether the SIGINT is used for exit/abort purposes and hence |
400 | a shellscript calling this program should discontinue. This is |
401 | hopefully obvious. If you just need to do some cleanup on SIGINT, but |
402 | then exit immediately, the answer is "yes". |
403 | |
404 | <p>If so, you have to tell the calling program about it by exiting |
405 | with the "I-exited-on-SIGINT" status. |
406 | |
407 | <p>There is no other way of doing this than to kill yourself with a |
408 | SIGINT signal. Do it by resetting the SIGINT handler to SIG_DFL, then |
409 | send yourself the signal. |
410 | |
411 | <PRE> |
412 | void sigint_handler(int sig) |
413 | { |
414 | <do some cleanup> |
415 | signal(SIGINT, SIG_DFL); |
416 | kill(getpid(), SIGINT); |
417 | } |
418 | </PRE> |
419 | |
420 | Notes: |
421 | |
422 | <MENU> |
423 | |
424 | <LI>You cannot "fake" the proper exit status by an exit(3) with a |
425 | special numeric value. People often assume this since the manuals for |
426 | shells often list some return value for exactly this. But this is just |
427 | a convention for your shell script. It does not work from one UNIX API |
428 | program to another. |
429 | |
430 | <P>All that happens is that the shell sets the "$?" variable to a |
431 | special numeric value for the convenience of your script, because your |
432 | script does not have access to the lower-lever UNIX status evaluation |
433 | functions. This is just an agreement between your script and the |
434 | executing shell, it does not have any meaning in other contexts. |
435 | |
436 | <P><LI>Do not use kill(0, SIGINT) without consulting the manul for |
437 | your OS implementation. I.e. on BSD, this would not send the signal to |
438 | the current process, but to all processes in the group. |
439 | |
440 | <P><LI>POSIX 1003.1 allows all these calls to appear in signal |
441 | handlers, so it is portable. |
442 | |
443 | </MENU> |
444 | |
445 | <p>In a bourne shell script, you can catch signals using the |
446 | <code>trap</code> command. Here, the same as for C programs apply. If |
447 | the intention of SIGINT is to end your program, you have to exit in a |
448 | way that the calling programs "sees" that you have been killed. If |
449 | you don't catch SIGINT, this happend automatically, but of you catch |
450 | SIGINT, i.e. to do cleanup work, you have to end the program by |
451 | killing yourself, not by calling exit. |
452 | |
453 | <p>Consider this example from FreeBSD's <code>mkdep</code>, which is a |
454 | bourne shell script. |
455 | |
456 | <pre> |
457 | TMP=_mkdep$$ |
458 | trap 'rm -f $TMP ; trap 2 ; kill -2 $$' 1 2 3 13 15 |
459 | </pre> |
460 | |
461 | Yes, you have to do it the hard way. It's even more annoying in shell |
462 | scripts than in C programs since you can't "pre-delete" temporary |
463 | files (which isn't really portable in C, though). |
464 | |
465 | <P>All this applies to programs in all languages, not only C and |
466 | bourne shell. Every language implementation that lets you catch SIGINT |
467 | should also give you the option to reset the signal and kill yourself. |
468 | |
469 | <P>It is always desireable to exit the right way, even if you don't |
470 | expect your usual callers to depend on it, some unusual one will come |
471 | along. This proper exit status will be needed for WCE and will not |
472 | hurt when the calling shell uses IUE or WUE. |
473 | |
474 | <H3>How to be a proper shell</H3> |
475 | |
476 | All this applies only for the script-executing case. Most shells will |
477 | also have interactive modes where things are different. |
478 | |
479 | <MENU> |
480 | |
481 | <LI>Do nothing special when SIGINT appears while you wait for a child. |
482 | You don't even have to remember that one happened. |
483 | |
484 | <P><LI>Wait for child to exit, get the exit status. Do not truncate it |
485 | to type char. |
486 | |
487 | <P><LI>Look at WIFSIGNALED(status) and WTERMSIG(status) to tell |
488 | whether the child says "I exited on SIGINT: in my opinion the user |
489 | wants the shellscript to be discontinued". |
490 | |
491 | <P><LI>If the latter applies, discontinue the script. |
492 | |
493 | <P><LI>Exit. But since a shellscript may in turn be called by a |
494 | shellscript, you need to make sure that you properly communicate the |
495 | discontinue intention to the calling program. As in any other program |
496 | (see above), do |
497 | |
498 | <PRE> |
499 | signal(SIGINT, SIG_DFL); |
500 | kill(getpid(), SIGINT); |
501 | </PRE> |
502 | |
503 | </MENU> |
504 | |
505 | <H3>Other remarks</H3> |
506 | |
507 | Although this web page talks about SIGINT only, almost the same issues |
508 | apply to SIGQUIT, including proper exiting by killing yourself after |
509 | catching the signal and proper reaction on the WIFSIGNALED(status) |
510 | value. One notable difference for SIGQUIT is that you have to make |
511 | sure that not the whole call tree dumps core. |
512 | |
513 | <H3>What to fight</H3> |
514 | |
515 | Make sure all programs <em>really</em> kill themselves if they react |
516 | to SIGINT or SIGQUIT and intend to abort their operation as a result |
517 | of this signal. Programs that don't use SIGINT/SIGQUIT as a |
518 | termination trigger - but as part of normal operation - don't kill |
519 | themselves, but do a normal exit instead. |
520 | |
521 | <p>Make sure people understand why you can't fake an exit-on-signal by |
522 | doing exit(...) using any numerical status. |
523 | |
524 | <p>Make sure you use a shell that behaves right. Especially if you |
525 | develop programs, since it will help seeing problems. |
526 | |
527 | <H3>Concrete examples how to fix programs:</H3> |
528 | <ul> |
529 | |
530 | <li>The fix for FreeBSD's |
531 | <A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/time/time.c.diff?r1=1.10&r2=1.11">time(1)</A>. This fix is the best example, it's quite short and clear and |
532 | it fixes a case where someone tried to fake signal exit status by a |
533 | numerical value. And the complete program is small. |
534 | |
535 | <p><li>Fix for FreeBSD's |
536 | <A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/main.c.diff?r1=1.9&r2=1.10">truss(1)</A>. |
537 | |
538 | <p><li>The fix for FreeBSD's |
539 | <A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/mkdep/mkdep.gcc.sh.diff?r1=1.8.2.1&r2=1.8.2.2">mkdep(1)</A>, a shell script. |
540 | |
541 | |
542 | <p><li>Fix for FreeBSD's make(1), <A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/make/job.c.diff?r1=1.9&r2=1.10">part 1</A>, |
543 | <A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/make/compat.c.diff?r1=1.10&r2=1.11">part 2</A>. |
544 | |
545 | </ul> |
546 | |
547 | <H3>Testsuite for shells</H3> |
548 | |
549 | I have a collection of shellscripts that test shells for the |
550 | behavior. See my <A HREF="download/">download dir</A> to get the newest |
551 | "sh-interrupt" files, either as a tarfile or as individual file for |
552 | online browsing. This isn't really documented, besides from the |
553 | comments the scripts echo. |
554 | |
555 | <H3>Appendix 1 - table of implementation choices</H3> |
556 | |
557 | <table border cellpadding=2> |
558 | |
559 | <tr valign=top> |
560 | <th>Method sign</th> |
561 | <th>Does what?</th> |
562 | <th>Example shells that implement it:</th> |
563 | <th>What happens when a shellscript called emacs, the user used |
564 | <code>C-g</code> and the script has additional commands in it?</th> |
565 | <th>What happens when a shellscript called emacs, the user did not use |
566 | <code>C-c</code> and the script has additional commands in it?</th> |
567 | <th>What happens if a non-interactive child catches SIGINT?</th> |
568 | <th>To behave properly, childs must do what?</th> |
569 | </tr> |
570 | |
571 | <tr valign=top align=left> |
572 | <td>IUE</td> |
573 | <td>The shell executing a script exits immediately if it receives |
574 | SIGINT.</td> |
575 | <td>4.4BSD ash (ash), NetBSD, FreeBSD prior to 3.0/22.8</td> |
576 | <td>The editor session is lost and subsequent commands are not |
577 | executed.</td> |
578 | <td>The editor continues as normal and the subsequent commands are |
579 | executed. </td> |
580 | <td>The scripts ends immediately, returning to the caller even before |
581 | the current foreground child of the shell exits. </td> |
582 | <td>It doesn't matter what the child does or how it exits, even if the |
583 | child continues to operate, the shell returns. </td> |
584 | </tr> |
585 | |
586 | <tr valign=top align=left> |
587 | <td>WUE</td> |
588 | <td>If the shell executing a script received SIGINT while a foreground |
589 | process was running, it will exit after that child's exit.</td> |
590 | <td>pdksh (OpenBSD /bin/sh)</td> |
591 | <td>The editor continues as normal, but subsequent commands from the |
592 | script are not executed.</td> |
593 | <td>The editor continues as normal and subsequent commands are |
594 | executed. </td> |
595 | <td>The scripts returns to its caller after the current foreground |
596 | child exits, no matter how the child exited. </td> |
597 | <td>It doesn't matter how the child exits (signal status or not), but |
598 | if it doesn't return at all, the shell will not return. In no case |
599 | will further commands from the script be executed. </td> |
600 | </tr> |
601 | |
602 | <tr valign=top align=left> |
603 | <td>WCE</td> |
604 | <td>The shell exits if a child signaled that it was killed on a |
605 | signal (either it had the default handler for SIGINT or it killed |
606 | itself). </td> |
607 | <td>bash (Linux /bin/sh), most commercial /bin/sh, FreeBSD /bin/sh |
608 | from 3.0/2.2.8.</td> |
609 | <td>The editor continues as normal and subsequent commands are |
610 | executed. </td> |
611 | <td>The editor continues as normal and subsequent commands are |
612 | executed. </td> |
613 | <td>The scripts returns to its caller after the current foreground |
614 | child exits, but only if the child exited with signal status. If |
615 | the child did a normal exit (even if it received SIGINT, but catches |
616 | it), the script will continue. </td> |
617 | <td>The child must be implemented right, or the user will not be able |
618 | to break shell scripts reliably.</td> |
619 | </tr> |
620 | |
621 | </table> |
622 | |
623 | <P><img src=linie.png width="100%" alt=" "> |
624 | <BR>©2005 Martin Cracauer <cracauer @ cons.org> |
625 | <A HREF="http://www.cons.org/cracauer/">http://www.cons.org/cracauer/</A> |
626 | <BR>Last changed: $Date: 2005/02/11 21:44:43 $ |
627 | </BODY></HTML> |