Краткий ответ: нет, но это экономит около ] 1 мс процессорного времени (на современных процессорах).
(Обратите внимание, что вы должны exec
только в конце сценария, потому что ничего после exec
будет работать).
Более длинный ответ:
Exec
заменяет образ процесса текущего процесса на образ процесса исполняемого файла, который вы выполняете.
Это означает, что в тот момент, когда вы выполняете, процесс оболочки, который полностью ли exec
ing уничтожается и заменяется программой exec
ed.
Если вы не exec
, оболочка разветвляется, execs в вилке и ожидает завершения дочернего процесса, собирая его статус возврата, в надежде, что впоследствии могут быть запущены дополнительные команды ( fork
+ exec
является стандартным процедура, с помощью которой порождаются новые команды).
Поскольку их нет, вилка
- пустая трата времени, и вы можете запустить ее напрямую и сэкономить на этой вилке
] время.
В большинстве случаев это, по сути, микрооптимизация, основанная на знании того, как процесс порождается в Unices.
Примечание: (спасибо ilkkachu )
Здесь есть небольшая семантическая разница, так это то, заботится ли процесс, порождающий сценарий, о том, как умирает программа, запущенная возможно-exec.
Если дочерний процесс, который может быть выполнен в exec, нормально завершает работу, форма exec и non-exec эквивалентны, поскольку сценарий оболочки перенаправляет последний ожидаемый статус выхода в свой собственный статус выхода.
Если, однако ребенок умирает из-за сигнала n
, тогда оболочка преобразует его в статус выхода 128 + n
, эффективно теряя информацию, о которой был передан сигнал.
(Информация не потеряно, если вы уверены, что ребенок никогда не выходит регулярно с кодом выхода > 128
, что обычно имеет место.). Когда вы выполняете exec, больше нет промежуточной оболочки, и информация о статусе выхода идет непосредственно к вызывающей стороне исполняемого скрипта (и информация о том, вышел ли дочерний элемент или был ли сигнализирован, сохраняется, поскольку нет промежуточной оболочки, чтобы объединить его в код выхода).
(Подробнее см. waitpid (2) ).