Wann wird ein trap handler genau ausgeführt?
Max Bernöcker
wenn ich einen trap definiere und das entsprechende Signal das
Shellskript nun erreicht, wann wird dann der trap handler bei den
verschiedenen shell ausgeführt?
Bei bash, dash und zsh hab ich das mal mir folgendem ausprobiert:
#######
f(){
echo "catched sig"
exit 1
}
trap f USR1
sleep 20
#######
Es sieht so aus, als ob der aktuell laufende Befehl (hier sleep) noch
abgearbeitet wird und dann erst der trap handler, wenn ich dem Skript
ein SIGUSR1 schicke.
Der Standard macht dazu wohl keine Aussage (zumindest kann ich aus
<http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html>
nichts herauslesen).
Allerdings steht auf <http://www.unix.com.ua/orelly/unix/ksh/ch08_04.htm>
(Learning the Korn Shell) etwas merkwürdiges:
| The syntax of trap is:
|
| trap cmd sig1 sig2 ...
|
| That is, when any of sig1, sig2, etc., are received, run cmd, then
| resume execution. After cmd finishes, the script resumes execution just
| after the command that was interrupted. [10]
|
| [10] This is what usually happens. Sometimes the command currently
| running will abort (sleep acts like this, as we'll see soon); other
| times it will finish running. Further details are beyond the scope of
| this book.
Wie ist es denn bei dem ganzen Rest?
Max
Juergen P. Meier
> Servus,
>
> wenn ich einen trap definiere und das entsprechende Signal das
> Shellskript nun erreicht, wann wird dann der trap handler bei den
> verschiedenen shell ausgeführt?
>
> Bei bash, dash und zsh hab ich das mal mir folgendem ausprobiert:
>
> #######
> f(){
> echo "catched sig"
buffered I/O auf Stdout. Schreib lieber
echo "catched sig" >&2
> exit 1
> }
>
> Es sieht so aus, als ob der aktuell laufende Befehl (hier sleep) noch
> abgearbeitet wird und dann erst der trap handler, wenn ich dem Skript
> ein SIGUSR1 schicke.
Das mag oder mag nicht so aussehen, weil stdout gepuffert ist.
> Der Standard macht dazu wohl keine Aussage (zumindest kann ich aus
><http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html>
> nichts herauslesen).
Was noch hinzukommt.
>| [10] This is what usually happens. Sometimes the command currently
>| running will abort (sleep acts like this, as we'll see soon); other
>| times it will finish running. Further details are beyond the scope of
>| this book.
>
> Wie ist es denn bei dem ganzen Rest?
Vermutlich kaum anders. Shell-builtins koennen durch einen generischen
Signalhandler idR. immer unterbrochen werden, externe Kommandos
reagieren dann schon mal recht eigen auf Signale.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Helmut Waitzmann
>Servus,
>
>wenn ich einen trap definiere und das entsprechende Signal das
>Shellskript nun erreicht, wann wird dann der trap handler bei den
>verschiedenen shell ausgeführt?
>Der Standard macht dazu wohl keine Aussage (zumindest kann ich aus
><http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html>
>nichts herauslesen).
[...]
>Wie ist es denn bei dem ganzen Rest?
Bei meinem »bash« (Ubuntu 7.10)
$ bash --version
GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
steht im Manual-Page:
If bash is waiting for a command to complete and receives a signal
for which a trap has been set, the trap will not be executed until
the command completes. When bash is waiting for an asynchronous
command via the wait builtin, the reception of a signal for which
a trap has been set will cause the wait builtin to return
immediately with an exit sta‐ tus greater than 128, immediately
after which the trap is executed.
--
Wer mir E-Mail schreiben will, stelle | When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen | precede my e-mail address with
Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <x...@example.net>, (Helmut Waitzmann) x...@example.net
Max Bernöcker
> Bei meinem »bash« (Ubuntu 7.10)
> [...]
> steht im Manual-Page:
> If bash is waiting for a command to complete and receives a signal
> for which a trap has been set, the trap will not be executed until
> the command completes. When bash is waiting for an asynchronous
> command via the wait builtin, the reception of a signal for which
> a trap has been set will cause the wait builtin to return
> immediately with an exit sta‐ tus greater than 128, immediately
> after which the trap is executed.
Ich hab da nur immer unter trap geschaut, danke fürs manual vorlesen.
Bei der dash hab ich jetzt in den source geschaut
<http://git.kernel.org/?p=utils/dash/dash.git;a=summary>
(ist wirklich einfach zu lesen), da ists genau so wie in der bash.
Max
p.s. Wers genau wissen will: src/eval.c, der Code ist selbstsprechend:
default:
/* Fork off a child process if necessary. */
if (!(flags & EV_EXIT) || trap[0]) {
INTOFF;
jp = makejob(cmd, 1);
if (forkshell(jp, cmd, FORK_FG) != 0) {
exitstatus = waitforjob(jp);
INTON;
break;
}
Max Bernöcker
> Max Bernöcker <zeopiu...@yahoo.de>:
>> Der Standard macht dazu wohl keine Aussage (zumindest kann ich aus
>><http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html>
>> nichts herauslesen).
> Was noch hinzukommt.
Ha, ich war nur zu blöd, das richtig zu lesen:
|When a signal for which a trap has been set is received while the shell
|is waiting for the completion of a utility executing a foreground
|command, the trap associated with that signal shall not be executed
|until after the foreground command has completed. When the shell is
|waiting, by means of the wait utility, for asynchronous commands to
|complete, the reception of a signal for which a trap has been set shall
|cause the wait utility to return immediately with an exit status >128,
|immediately after which the trap associated with that signal shall be
|taken.
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html>
Max