Une solution élégante est de créer un groupe de processus pour parexec et tous ses fils. Ceci se fait par un appel à setpgid(2) ou setpgrp(2) avant le premier fork.
Pour tuer tous les membres du groupe, il suffit alors d'un seul appel à kill(2) avec pour pid 0. Cela tue aussi bien les fils que parexec lui-même.
Dans compte, on utilise signal(2) ou sigaction(2) pour définir un handler pour tous les signaux. Comme indiqué dans signal(7), il existe (au plus) 31 signaux, numérotés de 1 à 31. Le handler doit afficher le numéro du signal (celui-ci lui est passé en argument). Le handler peut ensuite relancer le signal... après avoir restauré son comportement par défaut (SIG_DFL).
Notez ce qu'il advient de l'appel à sleep dans compte en cas de réception d'un signal...
Notez également que certains messages de compte peuvent être affichés alors que le shell a repris la main et affiché son prompt... Pourquoi? Pouvez-vous imaginer une solution à ce problème?