Fonds Linux
  1. Fonds Linux
  3. raison d'exec dans les scripts wrapper
Intereting Posts
Trouvez le numéro de ligne qui contient le model en utilisant un délimiteur d'expressions rationnelles personnalisé Activer numlock par défaut dans Linux Mint Comment les variables à l'intérieur des accolades sont évaluées Copier-coller entre l'hôte Hyper-V et l'hôte Comment find quel process est en train d'écrire sur le disque? Comment détecter le port sortant du PID Mosh: Conserver le backscroll au-delà de la hauteur de la window du terminal Comment interpréter la sortie de 'lsusb' – Quels sont tous ces hubs racine Linux Foundation? Puis-je automatiser les réponses y / N lors de l'installation avec yum? Recherche d'un grand nombre d'extensions avec find Pas de sortie colorée en less pour la command ls renommer les images pour inclure la date de création dans le nom if / then / else page de manuel Est-il possible d'get le message d'erreur de la command précédente qui a échoué lorsque la command conditionnelle s'exécute en utilisant || Archiver le file le plus ancien, où les files sont nommés en fonction de leur horodatage

raison d'exec dans les scripts wrapper

J'ai vu des exemples de script wrapper qui dans un nuthell sont les suivants: 

#!/bin/bash myprog=sleep echo "This is the wrapper script, it will exec "$myprog"" exec "$myprog" "$@"

Comme on l'a vu ci-dessus, ils utilisent exec pour replace le shell nouvellement créé presque immédiatement avec 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 le $myprog est démarré en tant que process enfant de l'instance bash.

Quels sont les avantages de la première approche?

Utiliser exec rend l'encapsuleur plus transparent, c'est-à-dire qu'il est less probable que l'user ou l'application qui appelle le script ait besoin de savoir que c'est un relais qui lance à son tour le programme «réel».

En particulier, si l'appelant veut tuer le programme, ils vont simplement tuer le process qu'ils viennent de lancer. Si le script wrapper exécute un process enfant, l'appelant doit savoir qu'il doit find l'enfant du wrapper et le tuer à la place. Le script d'encapsuleur pourrait définir un piège pour relayer certains signaux, mais cela ne fonctionnerait pas avec SIGSTOP ou SIGKILL qui ne peut pas être intercepté.

Appeler exec permet également d'économiser un peu de memory (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é à find le bon process à tuer, surcharge de memory, etc.).

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

Trouver aucun doublon … se référer au manuel de FreeBSD , qui donne une bonne raison:

L'instruction exec remplace le process shell par le programme spécifié. Si exec est omis, le process shell rest en memory pendant l'exécution du programme et consum inutilement les ressources système.

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