On 2006-02-17 10:56:58 +0100, Vincent Lefevre wrote:
On 2006-02-17 09:52:25 +0100, Christophe Martin wrote:
En general j'utilise ca : placer artificiellement le shell en mode attente de signal (un SIGCHLD ici). Du coup il reagit immediatement a tout signal. J'ai pas verifie la POSIX conformance.
echo $$ { while : ; do sleep 1000 ; done ; } & trap 'echo gnarf gnarf ; exit 0' USR1 wait
dans un autre shell : kill -USR1 pid-du-shell
Ça m'étonnerait que ce soit conforme à POSIX. Ça fonctionne avec bash 2.05b, mais POSIX ne dit pas que wait peut être interrompu par un signal trappé (en tout cas pas sous la description de "wait"). Ne serait-ce pas un bug de bash?
En fait, ce comportement sur le wait est décrit ailleurs, en section 2.11: 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. C'est donc un bug de zsh. Ceci dit, cette solution ne me convient pas, car elle crée un processus supplémentaire (et ce n'est pas élégant), et d'autre part, si pour une raison ou pour une autre le processus shell est tué trop brutalement (ça peut être un SIGKILL, non trappable), le processus fils continue de tourner (impossible de nettoyer). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA