Re: Comportement de bash: kill des fils

> Damned ! Me voilà sur la piste du 'process group'. Je savais que les processus
> était organisé en fonction d'une hiérarchie père/fils (voir pstree), mais
> je ne savais pas qu'il y avait ce 'process group'

Les détails que tu m'as donnés en privé sont un peu contradictoires --
si tu lances un script en background à partir d'un autre script, tu ne
peux pas utiliser '%1' dans le premier script pour référencer celui qui
est en background.
En gros : une session est composée de groupes de processus ; la session
a un terminal de contrôle ; parmi les groupes, un seul est dans le
foreground, les autres étant dans le background ; seul le groupe
foreground peut accéder au terminal de contrôle ; les signaux INT et QUIT
sont envoyés aux processus du groupe foreground ; les groupes background,
s'ils essayent de lire le terminal de contrôle, reçoivent le signal TTIN,
et le signal TTOU s'ils essayent d'écrire dessus (ce dernier point est
contrôlé par 'stty tostop') ; un processus peut changer de groupe ; un
processus peut créer un autre processus et lui assigner un autre groupe ;
un processus est un 'group leader' si son PID == PGID (pour un script, le
shell qui l'execute est le 'group leader').
Attention : 'bash' crée les groupes de processus différement s'il est en
interactif ou non ; en interactif, toutes les commandes sont placées dans un
groupe propre ; ce n'est pas toujours le cas en non-interactif.
Pour expérimenter :

sleep 1000 | cat &
ps -o pid,pgid,ppid,sid,tpgid,args

PID PGID PPID SID TPGID COMMAND
31942 31942 27528 27528 31944 sleep 100
31943 31942 27528 27528 31944 cat
31944 31944 27528 27528 31944 ps -o pid,pgid,ppid,sid,tpgid,args

'kill %1' enverra TERM à tous les processus du groupe. '%1' n'est pas
disponible dans un script ; '$!' le remplace : c'est le dernier processus
background lancé.
-Nicolas Tripon