raison de l'exec dans les scripts wrapper

J'ai vu des exemples de scripts wrapper qui en un mot sont les suivants:

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

exec "$myprog" "$@"

Comme vu ci-dessus, ils execremplacent presque immédiatement le nouveau shell créé par le $myprog. On pourrait réaliser la même chose sans exec:

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

"$myprog" "$@"

Dans ce dernier exemple, une nouvelle instance bash est démarrée puis $myprogdémarrée en tant que processus enfant de l'instance bash.

Quels sont les avantages de la première approche?

L'utilisation execrend l'encapsuleur plus transparent, c'est-à-dire qu'il est moins probable que l'utilisateur ou l'application qui appelle le script doive être conscient qu'il s'agit d'un relais qui à son tour lance le «vrai» programme.

En particulier, si l'appelant veut tuer le programme, il ne fera que tuer le processus qu'il vient de lancer. Si le script d'encapsuleur exécute un processus enfant, l'appelant devrait savoir qu'il doit trouver l'enfant de l'encapsuleur et le tuer à la place. Le script wrapper pourrait définir un piège pour relayer certains signaux, mais cela ne fonctionnerait pas avec SIGSTOP ou SIGKILL qui ne peuvent pas être interceptés.

L'appel execéconomise également un peu de mémoire (et d'autres ressources telles que les PID, etc.) car il n'y a pas besoin de garder un shell supplémentaire avec rien à faire.

S'il y a plusieurs wrappers, les problèmes s'additionnent (difficulté à trouver le bon processus à tuer, surcharge de mémoire, etc.).

Certains shells (par exemple le shell Korn) détectent automatiquement quand une commande est la dernière et il n'y a pas d'interruption active et mettent un implicite exec, mais pas tous (par exemple pas bash).

Trouver aucun doublon ... reportez-vous au manuel de FreeBSD , qui donne une raison suffisante:

L' execinstruction remplace le processus shell par le programme spécifié. Si execest omis, le processus shell reste en mémoire pendant l'exécution du programme et consomme inutilement des ressources système.

ce qui est essentiellement la raison qui m'a été expliquée il y a longtemps (par l'un des porteurs) et qui est assez bien connue.