j'ai un script bash pere qui lance des scripts bash fils
Ces fils doivent afficher des retours a l'ecran.
Ils n'affichent pas ce que je veux lorsque je leur envoie un signal.
Premier cas, qui fonctionne:
aaa@darkstar:~$ cat fils
#! /bin/bash
PID=3D$$
mort()
{
echo "je suis tue par un INT"
exit 0
}
trap mort INT
echo je suis le fils et mon PID est $PID
while [ true ]
do
true
done
aaa@darkstar:~$ ./fils
je suis le fils et mon PID est 16036
(depuis une deuxieme console, je lance un kill -INT 16036)
je suis tue par un INT
aaa@darkstar:~$
Maintenant avec un pere:
aaa@darkstar:~$ cat pere
#! /bin/bash
echo "je suis le pere"
./fils &
sleep 30
aaa@darkstar:~$./pere
je suis le pere
je suis le fils et mon PID est 16039
(envoi d'un kill -INT 16039 --> rien!)
(envoi d'un kill -9 16039 -> le fils meurt)
(30 secondes plus tard)
./pere: line 4: 16039 Processus arr=EAt=E9 ./fils
aaa@darkstar:~$
1=2E pourquoi le fils ne meurt pas lors du INT?
2=2E comment faire pour que le fils affiche sur la console sa
mort?
C'est un peu court, allez hop, le reste de ton message n'explique pas pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir et/ou traiter le INT clavier contrairement au premier paragraphe du
Oups, en repassant je me rend compte que je confond encore, reste le jobs -p, et l'absence d'explication concernant d'eventuels comportements divergants suivant que l'on execute un script shell (dont les initialisations sont suceptibles de foutre le bordel :) ou autre chose ds dans le job/pipeline async, POSIX doit la aussi definir pas mal de choses... bonne chasse ;)
xavier.
Le 05-01-2006, Xavier Gachon <xavier@shagshag.frmug.org> a écrit :
C'est un peu court, allez hop, le reste de ton message n'explique pas
pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir
et/ou traiter le INT clavier contrairement au premier paragraphe du
Oups, en repassant je me rend compte que je confond encore, reste le
jobs -p, et l'absence d'explication concernant d'eventuels comportements
divergants suivant que l'on execute un script shell (dont les initialisations
sont suceptibles de foutre le bordel :) ou autre chose ds dans le
job/pipeline async, POSIX doit la aussi definir pas mal de choses...
bonne chasse ;)
C'est un peu court, allez hop, le reste de ton message n'explique pas pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir et/ou traiter le INT clavier contrairement au premier paragraphe du
Oups, en repassant je me rend compte que je confond encore, reste le jobs -p, et l'absence d'explication concernant d'eventuels comportements divergants suivant que l'on execute un script shell (dont les initialisations sont suceptibles de foutre le bordel :) ou autre chose ds dans le job/pipeline async, POSIX doit la aussi definir pas mal de choses... bonne chasse ;)
xavier.
Vincent Lefevre
Dans l'article , Xavier Gachon écrit:
Le 05-01-2006, Vincent Lefevre <vincent+ a écrit :
raison pour laquelle j'avais orienté sur ces sections de la documentation bash/libc. Oui, c'est documenté dans le man de bash (la libc n'a rien à faire
ici, d'ailleurs zsh avec la même libc se comporte différemment).
La _doc_ de la libc qui se veut +-POSIX se repand en long en large et en traver sur les details du job control, contrairement a POSIX lorsqu'on se limite aux sections shell. Parler de conformité POSIX hors libc est un tantinet osé!
Là ça ne concernait pas le job control (enfin, c'est bash qui cherche à faire intervenir du job control, mais c'est son problème).
Mais d'après ce que tu dis (et c'était aussi mon interprétation),
Tu aurais du l'explicité; nous aurions gagné du temps.
Je voulais surtout dire que la norme était confuse.
bash n'est pas conforme à POSIX (et zsh l'est).
C'est un peu court, allez hop, le reste de ton message n'explique pas pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir et/ou traiter le INT clavier contrairement au premier paragraphe du "2.11 Signal and Error Handling" de POSIX (vu precedemment) et a bash.
Il ne le fait pas par défaut. En revanche, dès qu'il y a un trap dans le fils, la commande n'est pas interrompue par le signal (note: c'est le handler qui termine la commande, pas le signal lui-même), donc propager le signal au fils me semble le bon choix. Le problème est que le shell ne peut pas savoir si le fils a fait un trap ou non! Donc du coup, le kill -INT <fils> ne tue pas le processus fils quand il n'y a pas de trap.
Donc, d'apres notre interpretation, aucun des deux n'est POSIX, dur!
Je pense que tel que c'est dit, il est impossible d'être POSIX.
pi la sortie (au moins par defaut) de jobs -p sous zsh n'est pas conforme et ca c'est grave!!! %)</grin>
Bug rapporté via le BTS de Debian.
Mais je ne me jetterais pas dans une discussion sur la conformité POSIX (sans meme parler des versions/evolutions de celle-ci) d'un shell quelconque ici. C'est le genre de sujet a peter les plombs a court terme vu la gueule de POSIX; Meme les discussions sans fin concernant la conformités de compilateurs de langages divers et variés a des normes ISO (ou pas :) sont moins casse gueule... lorsqu'en plus il semble y avoir un parti pris, bonjour l'horreur, et je ne parle meme pas de la validité/coherence du contenu des normes/specs/std en question :-)
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est pas POSIX. :)
Dans l'article <slrndrrc7j.1nv.user@elendil.avalon.ombres.org>,
Xavier Gachon <xavier@shagshag.frmug.org> écrit:
Le 05-01-2006, Vincent Lefevre <vincent+news@vinc17.org> a écrit :
raison pour laquelle j'avais orienté sur ces sections de la
documentation bash/libc.
Oui, c'est documenté dans le man de bash (la libc n'a rien à faire
ici, d'ailleurs zsh avec la même libc se comporte différemment).
La _doc_ de la libc qui se veut +-POSIX se repand en long en
large et en traver sur les details du job control, contrairement
a POSIX lorsqu'on se limite aux sections shell. Parler de conformité
POSIX hors libc est un tantinet osé!
Là ça ne concernait pas le job control (enfin, c'est bash qui cherche
à faire intervenir du job control, mais c'est son problème).
Mais d'après ce que tu dis (et c'était aussi mon interprétation),
Tu aurais du l'explicité; nous aurions gagné du temps.
Je voulais surtout dire que la norme était confuse.
bash n'est pas conforme à POSIX (et zsh l'est).
C'est un peu court, allez hop, le reste de ton message n'explique pas
pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir
et/ou traiter le INT clavier contrairement au premier paragraphe du
"2.11 Signal and Error Handling" de POSIX (vu precedemment) et a bash.
Il ne le fait pas par défaut. En revanche, dès qu'il y a un trap dans
le fils, la commande n'est pas interrompue par le signal (note: c'est
le handler qui termine la commande, pas le signal lui-même), donc
propager le signal au fils me semble le bon choix. Le problème est
que le shell ne peut pas savoir si le fils a fait un trap ou non!
Donc du coup, le kill -INT <fils> ne tue pas le processus fils quand
il n'y a pas de trap.
Donc, d'apres notre interpretation, aucun des deux n'est POSIX, dur!
Je pense que tel que c'est dit, il est impossible d'être POSIX.
pi la sortie (au moins par defaut) de jobs -p sous zsh n'est pas conforme
et ca c'est grave!!! %)</grin>
Bug rapporté via le BTS de Debian.
Mais je ne me jetterais pas dans une discussion sur la conformité
POSIX (sans meme parler des versions/evolutions de celle-ci) d'un
shell quelconque ici. C'est le genre de sujet a peter les plombs
a court terme vu la gueule de POSIX; Meme les discussions sans fin
concernant la conformités de compilateurs de langages divers et variés
a des normes ISO (ou pas :) sont moins casse gueule... lorsqu'en plus il
semble y avoir un parti pris, bonjour l'horreur, et je ne parle meme
pas de la validité/coherence du contenu des normes/specs/std en
question :-)
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est
pas POSIX. :)
Le 05-01-2006, Vincent Lefevre <vincent+ a écrit :
raison pour laquelle j'avais orienté sur ces sections de la documentation bash/libc. Oui, c'est documenté dans le man de bash (la libc n'a rien à faire
ici, d'ailleurs zsh avec la même libc se comporte différemment).
La _doc_ de la libc qui se veut +-POSIX se repand en long en large et en traver sur les details du job control, contrairement a POSIX lorsqu'on se limite aux sections shell. Parler de conformité POSIX hors libc est un tantinet osé!
Là ça ne concernait pas le job control (enfin, c'est bash qui cherche à faire intervenir du job control, mais c'est son problème).
Mais d'après ce que tu dis (et c'était aussi mon interprétation),
Tu aurais du l'explicité; nous aurions gagné du temps.
Je voulais surtout dire que la norme était confuse.
bash n'est pas conforme à POSIX (et zsh l'est).
C'est un peu court, allez hop, le reste de ton message n'explique pas pourquoi zsh lorsque le fils est asynchrone laisse celui-ci recevoir et/ou traiter le INT clavier contrairement au premier paragraphe du "2.11 Signal and Error Handling" de POSIX (vu precedemment) et a bash.
Il ne le fait pas par défaut. En revanche, dès qu'il y a un trap dans le fils, la commande n'est pas interrompue par le signal (note: c'est le handler qui termine la commande, pas le signal lui-même), donc propager le signal au fils me semble le bon choix. Le problème est que le shell ne peut pas savoir si le fils a fait un trap ou non! Donc du coup, le kill -INT <fils> ne tue pas le processus fils quand il n'y a pas de trap.
Donc, d'apres notre interpretation, aucun des deux n'est POSIX, dur!
Je pense que tel que c'est dit, il est impossible d'être POSIX.
pi la sortie (au moins par defaut) de jobs -p sous zsh n'est pas conforme et ca c'est grave!!! %)</grin>
Bug rapporté via le BTS de Debian.
Mais je ne me jetterais pas dans une discussion sur la conformité POSIX (sans meme parler des versions/evolutions de celle-ci) d'un shell quelconque ici. C'est le genre de sujet a peter les plombs a court terme vu la gueule de POSIX; Meme les discussions sans fin concernant la conformités de compilateurs de langages divers et variés a des normes ISO (ou pas :) sont moins casse gueule... lorsqu'en plus il semble y avoir un parti pris, bonjour l'horreur, et je ne parle meme pas de la validité/coherence du contenu des normes/specs/std en question :-)
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est pas POSIX. :)
Le 06-01-2006, Vincent Lefevre <vincent+ a écrit :
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est pas POSIX. :)
bah non :)
Tiens un autre pour la route et valable pour bash comme zsh (par defaut) qu'on vient de me rappeler, "time" en tant que mot reservé (pas POSIX) ne peut etre desactivé comme un builtin mais lorsqu'il precede un pipeline les redirections ne s'appliquent qu'au pipeline pas a time lui meme, d'ou la necessité de le placer entre {} pour rediriger sa sortie (sur stderr par defaut) de façon independante du pipeline qu'il "mesure" redirections comprises (ou d'autres nombreuses solutions) ;)
xavier.
Le 06-01-2006, Vincent Lefevre <vincent+news@vinc17.org> a écrit :
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est
pas POSIX. :)
bah non :)
Tiens un autre pour la route et valable pour bash comme zsh (par defaut)
qu'on vient de me rappeler, "time" en tant que mot reservé (pas POSIX)
ne peut etre desactivé comme un builtin mais lorsqu'il precede un pipeline
les redirections ne s'appliquent qu'au pipeline pas a time lui meme, d'ou
la necessité de le placer entre {} pour rediriger sa sortie (sur stderr
par defaut) de façon independante du pipeline qu'il "mesure" redirections
comprises (ou d'autres nombreuses solutions) ;)
Le 06-01-2006, Vincent Lefevre <vincent+ a écrit :
Du coup on ne peut plus trop se plaindre du sh de Solaris qui n'est pas POSIX. :)
bah non :)
Tiens un autre pour la route et valable pour bash comme zsh (par defaut) qu'on vient de me rappeler, "time" en tant que mot reservé (pas POSIX) ne peut etre desactivé comme un builtin mais lorsqu'il precede un pipeline les redirections ne s'appliquent qu'au pipeline pas a time lui meme, d'ou la necessité de le placer entre {} pour rediriger sa sortie (sur stderr par defaut) de façon independante du pipeline qu'il "mesure" redirections comprises (ou d'autres nombreuses solutions) ;)
