Une petite question... avec un shell POSIX (sans supposition supplémentaire), est-il possible d'attendre un signal pour terminer avec un code de retour nul une fois le signal en question reçu? Évidemment, je veux une méthode suffisamment élégante et sans défaut (pas d'attente active consommant du temps CPU et la terminaison du processus doit être immédiate au sens strict du terme). C'est bien le processus shell qui doit recevoir le signal, pas un de ses fils.
C'était le genre de script plus simple à écrire en shell qu'en Perl, surtout qu'il doit faire un "source" pour récupérer des variables d'environnement (à passer à un des processus fils du script). Pour le moment, je pense terminer le script par un "exec perl ..." où le petit script Perl contient un trap et fait un "POSIX::pause" (voire un sleep si le module POSIX est inexistant).
Salut encore
Vincent Lefevre a écrit :
Une petite question... avec un shell POSIX (sans supposition supplémentaire), est-il possible d'attendre un signal pour terminer avec un code de retour nul une fois le signal en question reçu? Évidemment, je veux une méthode suffisamment élégante et sans défaut (pas d'attente active consommant du temps CPU et la terminaison du processus doit être immédiate au sens strict du terme). C'est bien le processus shell qui doit recevoir le signal, pas un de ses fils.
C'était le genre de script plus simple à écrire en shell qu'en Perl, surtout qu'il doit faire un "source" pour récupérer des variables d'environnement (à passer à un des processus fils du script). Pour le moment, je pense terminer le script par un "exec perl ..." où le petit script Perl contient un trap et fait un "POSIX::pause" (voire un sleep si le module POSIX est inexistant).
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
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?
Et ça ne fonctionne pas avec zsh 4.2.6.
Vincent Lefevre a écrit :
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?
ca marche aussi avec dash, et solaris ksh... bug ou feature va savoir.
Et ça ne fonctionne pas avec zsh 4.2.6.
bon a mettre dans le tiroirs des pas portables donc.
sinon y'a moins bien mais c'est plus cher (en CPU et temps de reponse)
trap 'exit 0' USR1 while : do sleep 1 ; done
sinon....
On 2006-02-17 11:10:09 +0100, Christophe Martin wrote:
trap 'exit 0' USR1 while : do sleep 1 ; done
C'est justement ce que je ne voulais pas.
On 2006-02-17 11:30:18 +0100, Christophe Martin wrote:
Te reste plus qu'a virer du cote obscure : utilise bash, ksh, dash ;-)
Ce n'est même pas satisfaisant, car ces shells ne sont pas forcément installés. Et s'il s'agit d'un bug, le comportement pourrait très bien changer. En plus, la solution proposée n'est pas jolie. Reste plus qu'à me tourner vers un vrai langage de programmation: Perl.
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).
Salut a toutes et a tous !
Vincent Lefevre a écrit :
On 2006-02-17 10:56:58 +0100, Vincent Lefevre wrote:
[Zlap!]
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).
un peu de jugeote STP ! Si { while : ; do sleep 1000 ; done }& wait ne te convient pas car il consomme 2, (et non pas 1 processus), et ne resiste ni a l'eau ni aux bombes nucleaires (ce qui n'etait pas precise au depart), tu peux toujours essayer while : ; do sleep 1000 & wait ; done qui lui resiste au lavage a 90, le slip sale disparait tout seul dans le pire des cas au bout de 1000 secondes.
N'y aurait-il pas quelque mauvaise foi dans tes propos relatifs a l'elegance ? Lancer perl, chercher pleins de modules fournissant je ne sais quelle fonctionnalite pour a la fin du compte se rabattre sur sleep/wait (tes propres dire) : l'autre jour tu declarais :
un "exec perl ..." où le petit script Perl contient un trap et fait un "POSIX::pause" (voire un sleep si le module POSIX est inexistant).
c'est pas vraiment, AMHA, quelque chose qu'on peut qualifier de leger, fin, elegant...
A+ pour des discussions esthetiques.
Christophe
On 2006-02-20 14:35:38 +0100, Christophe Martin wrote:
un peu de jugeote STP ! Si { while : ; do sleep 1000 ; done }& wait ne te convient pas car il consomme 2, (et non pas 1 processus), et ne resiste ni a l'eau ni aux bombes nucleaires (ce qui n'etait pas precise au depart), tu peux toujours essayer while : ; do sleep 1000 & wait ; done qui lui resiste au lavage a 90, le slip sale disparait tout seul dans le pire des cas au bout de 1000 secondes.
Il y a un processus de trop: le sleep (en plus du zsh).
N'y aurait-il pas quelque mauvaise foi dans tes propos relatifs a l'elegance ? Lancer perl, chercher pleins de modules fournissant je ne sais quelle fonctionnalite pour a la fin du compte se rabattre sur sleep/wait (tes propres dire) : l'autre jour tu declarais :
un "exec perl ..." où le petit script Perl contient un trap et fait un "POSIX::pause" (voire un sleep si le module POSIX est inexistant).
c'est pas vraiment, AMHA, quelque chose qu'on peut qualifier de leger, fin, elegant...
C'est peut-être moins léger, mais il y a un Emacs à côté; c'est donc négligeable (surtout que ce n'est pas le seul script Perl qui tourne, et on bénéficie du partage de la mémoire pour l'exécutable).
Je veux surtout éviter un processus supplémentaire, notamment pour y voir plus clair dans mes ps, etc. Un
exec perl -e \ 'use strict; use POSIX; $SIG{"TERM"} = sub { exit }; POSIX::pause'
fonctionne bien.
-
Christophe Martin -
Vincent Lefevre