причина exec в скриптах-обёртках


28

Я видел примеры сценариев-оболочек, которые в двух словах следующие:

#!/bin/bash

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

exec "$myprog" "$@"

Как видно выше, они execпочти сразу же заменяют вновь созданную оболочку на $myprog. Можно добиться того же без exec:

#!/bin/bash

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

"$myprog" "$@"

В этом последнем примере новый экземпляр bash запускается, а затем $myprogзапускается как дочерний процесс экземпляра bash.

Каковы преимущества первого подхода?



Ответы:


32

Использование execделает обертку более прозрачной, т. Е. Снижает вероятность того, что пользователь или приложение, вызывающее скрипт, должно знать, что это реле, которое, в свою очередь, запускает «настоящую» программу.

В частности, если вызывающая сторона хочет уничтожить программу, она просто уничтожит только что запущенный процесс. Если сценарий оболочки запускает дочерний процесс, вызывающая сторона должна знать, что он должен выяснить дочерний элемент оболочки и уничтожить его. Скрипт-обертка может установить ловушку для передачи некоторых сигналов, но это не сработает с SIGSTOP или SIGKILL, которые не могут быть перехвачены.

Вызов execтакже экономит немного памяти (и других ресурсов, таких как PID и т. Д.), Так как нет необходимости хранить дополнительную оболочку, и ничего не остается делать.

Если имеется несколько оболочек, проблемы складываются (трудности с поиском подходящего процесса для уничтожения, перегрузки памяти и т. Д.).

Некоторые оболочки (например, оболочка Korn) автоматически определяют, когда команда является последней, и нет активной ловушки, и ставят неявные exec, но не все это делают (например, не bash).


10

Не найдя дубликатов ... обратитесь к руководству FreeBSD , которое дает достаточно вескую причину:

execЗаявление заменяет оболочки процесса с заданной программой. Если этот параметр execопущен, процесс оболочки остается в памяти во время выполнения программы и без необходимости потребляет системные ресурсы.

что, по сути, является причиной, объясненной мне довольно давно (одним из носильщиков), и довольно хорошо известно.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.