Каковы применения команды exec в сценариях оболочки?

Question

Каковы применения команды exec в сценариях оболочки?

174

Может ли кто-нибудь объяснить, что использует команда exec в сценариях оболочки с помощью простых примеров?

user2400564 21 авг. 2013, в 09:05

Источник

0

linux.about.com/od/commands/l/blcmdln_exec.htm это даст вам лучшее понимание
Mari 21 авг. 2013, в 07:31
27

Ссылки на linux.about.com не являются полезными. Они не дают удаленного понимания того, как выполнение команды или конвейера команд с использованием 'exec' отличается от обычного их выполнения. Отсюда вопрос ОП "в чем польза exec"?
Jonathan Hartley 28 апр. 2014, в 13:43
1

Stack Overflow - сайт для вопросов программирования и разработки. Этот вопрос, кажется, не по теме, потому что он не о программировании или разработке. Смотрите, какие темы я могу задать здесь, в Справочном центре. Возможно, лучше спросить Super User или Unix & Linux Stack Exchange .
jww 26 янв. 2018, в 21:33

Показать ещё 1 комментарий

Теги:

shell

unix

exec

2 ответа

19

Чтобы увеличить принятый ответ с кратким кратким ответом на новичок, вам, вероятно, не нужно exec.

Если вы все еще здесь, следующее обсуждение должно, мы надеемся, объяснить, почему. Когда вы запустите, скажем,

sh -c 'command'

вы запускаете экземпляр sh, а затем запустите command как дочерний экземпляр этого экземпляра sh. Когда command завершается, экземпляр sh также заканчивается.

sh -c 'exec command'

запускает экземпляр sh, затем заменяет экземпляр sh двоичным кодом command и запускает его вместо этого.

Конечно, обе эти функции бесполезны в этом ограниченном контексте; вы просто хотите

command

Есть несколько ситуаций, когда вы хотите, чтобы оболочка прочитала свой файл конфигурации или каким-то иным образом настроила среду в качестве подготовки к запуску command. Это в значительной степени единственная ситуация, когда exec command полезен.

#!/bin/sh
ENVIRONMENT=$(some complex task)
exec command

Это делает некоторые вещи для подготовки среды, чтобы она содержала то, что нужно. После этого экземпляр sh больше не нужен, и поэтому он (небольшая) оптимизация просто заменит экземпляр sh на процесс command, вместо того, чтобы sh запускать его как дочерний процесс и подождите, а затем выйдите, как только закончите.

Аналогично, если вы хотите освободить как можно больше ресурсов для тяжелой команды в конце оболочки script, вы можете захотеть exec эту команду в качестве оптимизации.

Если что-то заставляет вас запускать sh, но вы действительно хотели запустить что-то еще, exec something else - это, конечно, обходной путь для замены нежелательного экземпляра sh (например, если вы действительно хотите запустить свой собственный spiffy gosh вместо sh, но ваш не указан в /etc/shells, поэтому вы не можете указать его как свою оболочку для входа).

Второе использование exec для управления файловыми дескрипторами - отдельная тема. В принятом ответе это хорошо сказано; чтобы сохранить это самодостаточным, я просто отнесусь к руководству для чего-либо, где exec следует перенаправление вместо имени команды.

tripleee 26 июль 2016, в 06:41

0

Спасибо tripleee за отличный ответ и голосование. Хотите знать, как можно выполнить два способа: (1) bash -c "<command>" , (2) bash -c "exec <command>" , затем после выполнения я проверяю состояние возврата с помощью $? Интересно, есть ли различия? В обоих случаях $? отслеживание, если <command> прошла успешно? Или отслеживание, если сама оболочка в порядке?
Lin Ma 26 июль 2016, в 05:20
2

Не поддавайтесь искушению назвать свой bush изящной скорлупы. Конечно, это относится и к bash или вообще к любой популярной оболочке Unix; хотя, как отмечает @anishsane, Bash тайно оптимизирует bash -c 'command' , фактически выполняя exec command
tripleee 26 июль 2016, в 05:21
1

Код выхода оболочки, как правило, является кодом выхода последней выполненной команды. Конечно, если оболочка не запускается или не выполняет команду, состояние выхода оболочки будет отражать это с подходящим кодом ошибки.
tripleee 26 июль 2016, в 05:25
0

Спасибо, tripleee, проголосуйте за оба сообщения и задаетесь вопросом, понимает ли exec условное выполнение bash, как || и && ? Благодарю.
Lin Ma 26 июль 2016, в 05:43
1

Следует избегать последующих вопросов. Благодарю. Небольшой эксперимент покажет, что происходит, когда вы пытаетесь bash -c 'exec nonesvch || echo still here' (подсказка: это не echo и код выхода 127).
tripleee 26 июль 2016, в 05:55
1

В моей книге нет смысла использовать sh -c command ; Вы могли бы также написать command и это имело бы практически тот же эффект, с одним меньшим процессом. Итак, первый раздел этого ответа действительно бесполезен - как вы продолжаете признавать. Вы можете использовать exec чтобы завершить скрипт и заменить его любой командой, которую вы выполняете; это сокращает количество процессов и выводит оболочку из цикла при сообщении о состоянии выхода.
Jonathan Leffler 26 июль 2016, в 06:05
2

@JonathanLeffler Я намеренно документирую антипаттерн, который вижу в вопросах новичка. Этот был вызван этим дубликатом, но я видел его раньше, поэтому я хотел осветить это конкретно.
tripleee 26 июль 2016, в 06:07
1

Тогда нужно уточнить первый абзац - много. Сейчас это не так. В настоящее время он говорит: «вам не нужна exec command потому что вы можете использовать sh -c command ». Если это не то, что вы хотите сказать, вы должны пересмотреть язык, чтобы сделать его на 100% явным. Дай мне знать, когда ты его пересмотрел.
Jonathan Leffler 26 июль 2016, в 06:09
2

@JonathanLeffler Незначительная настройка формулировки; это достаточно, как вы думаете? Спасибо за ответ.
tripleee 26 июль 2016, в 06:12
1

Лучше, но ... хорошо, вы можете использовать exec command когда команда является последним оператором в сценарии, а не просто command . Я думаю, что я бы предпочел большую переписать.
Jonathan Leffler 26 июль 2016, в 06:22
2

Спасибо - я добавил еще один короткий абзац об этой оптимизации. Мне не совсем понятно, есть ли у вас другие возражения или вы просто хотите объяснить вещи под другим углом.
tripleee 26 июль 2016, в 06:30

Показать ещё 9 комментариев

Ещё вопросы

linux.about.com/od/commands/l/blcmdln_exec.htm это даст вам лучшее понимание
Ссылки на linux.about.com не являются полезными. Они не дают удаленного понимания того, как выполнение команды или конвейера команд с использованием 'exec' отличается от обычного их выполнения. Отсюда вопрос ОП "в чем польза exec"?
Stack Overflow - сайт для вопросов программирования и разработки. Этот вопрос, кажется, не по теме, потому что он не о программировании или разработке. Смотрите, какие темы я могу задать здесь, в Справочном центре. Возможно, лучше спросить Super User или Unix & Linux Stack Exchange .
Спасибо tripleee за отличный ответ и голосование. Хотите знать, как можно выполнить два способа: (1) bash -c "<command>" , (2) bash -c "exec <command>" , затем после выполнения я проверяю состояние возврата с помощью $? Интересно, есть ли различия? В обоих случаях $? отслеживание, если <command> прошла успешно? Или отслеживание, если сама оболочка в порядке?
Не поддавайтесь искушению назвать свой bush изящной скорлупы. Конечно, это относится и к bash или вообще к любой популярной оболочке Unix; хотя, как отмечает @anishsane, Bash тайно оптимизирует bash -c 'command' , фактически выполняя exec command
Код выхода оболочки, как правило, является кодом выхода последней выполненной команды. Конечно, если оболочка не запускается или не выполняет команду, состояние выхода оболочки будет отражать это с подходящим кодом ошибки.
Спасибо, tripleee, проголосуйте за оба сообщения и задаетесь вопросом, понимает ли exec условное выполнение bash, как || и && ? Благодарю.
Следует избегать последующих вопросов. Благодарю. Небольшой эксперимент покажет, что происходит, когда вы пытаетесь bash -c 'exec nonesvch || echo still here' (подсказка: это не echo и код выхода 127).
В моей книге нет смысла использовать sh -c command ; Вы могли бы также написать command и это имело бы практически тот же эффект, с одним меньшим процессом. Итак, первый раздел этого ответа действительно бесполезен - как вы продолжаете признавать. Вы можете использовать exec чтобы завершить скрипт и заменить его любой командой, которую вы выполняете; это сокращает количество процессов и выводит оболочку из цикла при сообщении о состоянии выхода.
@JonathanLeffler Я намеренно документирую антипаттерн, который вижу в вопросах новичка. Этот был вызван этим дубликатом, но я видел его раньше, поэтому я хотел осветить это конкретно.
Тогда нужно уточнить первый абзац - много. Сейчас это не так. В настоящее время он говорит: «вам не нужна exec command потому что вы можете использовать sh -c command ». Если это не то, что вы хотите сказать, вы должны пересмотреть язык, чтобы сделать его на 100% явным. Дай мне знать, когда ты его пересмотрел.
@JonathanLeffler Незначительная настройка формулировки; это достаточно, как вы думаете? Спасибо за ответ.
Лучше, но ... хорошо, вы можете использовать exec command когда команда является последним оператором в сценарии, а не просто command . Я думаю, что я бы предпочел большую переписать.
Спасибо - я добавил еще один короткий абзац об этой оптимизации. Мне не совсем понятно, есть ли у вас другие возражения или вы просто хотите объяснить вещи под другим углом.

cdarke · Accepted Answer · 2013-08-21T08-36-00.000Z

В ядре встроена функция встроенной команды exec, существует семейство из них на основе execve, которое обычно вызывается из C.

exec заменяет текущую программу в текущем процессе, без fork нового процесса. Это не то, что вы будете использовать в каждом script, который вы пишете, но это пригодится. Вот некоторые сценарии, которые я использовал:

Мы хотим, чтобы пользователь запускал определенную прикладную программу без доступа к оболочке. Мы могли бы изменить программу входа в /etc/passwd, но, возможно, мы хотим, чтобы настройки среды использовались из файлов запуска. Итак, в (скажем) .profile, последнее утверждение говорит что-то вроде:
```
 exec appln-program
```
поэтому теперь нет оболочки для возврата. Даже если appln-program выходит из строя, конечный пользователь не может попасть в оболочку, потому что его нет - exec заменил его.
Мы хотим использовать другую оболочку в файле /etc/passwd. Как ни странно, некоторые сайты не позволяют пользователям изменять свою панель входа. Один из сайтов, который я знаю, начинал с csh, и все просто вставляли в свой .login (файл запуска csh) вызов ksh. В то время как это сработало, он оставил запущенный процесс csh, и выход был двухступенчатым, что могло запутать. Поэтому мы изменили его на exec ksh, который только что заменил программу c-shell оболочкой korn, и сделал все проще (есть и другие проблемы с этим, например, тот факт, что ksh не является оболочкой входа).
Просто для сохранения процессов. Если мы назовем prog1 -> prog2 -> prog3 -> prog4 и т.д. И никогда не вернемся, сделайте каждый вызов exec. Это экономит ресурсы (не много, правда, если не повторяется) и упрощает выключение.

Вы, очевидно, видели exec где-то, возможно, если бы вы показали код, который прослушивал вас, мы могли бы оправдать его использование.

Изменить. Я понял, что мой ответ выше не завершен. Существуют два использования exec в оболочках типа ksh и bash - используются для открытия дескрипторов файлов. Вот несколько примеров:

exec 3< thisfile          # open "thisfile" for reading on file descriptor 3
exec 4> thatfile          # open "thatfile" for writing on file descriptor 4
exec 8<> tother           # open "tother" for reading and writing on fd 8
exec 6>> other            # open "other" for appending on file descriptor 6
exec 5<&0                 # copy read file descriptor 0 onto file descriptor 5
exec 7>&4                 # copy write file descriptor 4 onto 7
exec 3<&-                 # close the read file descriptor 3
exec 6>&-                 # close the write file descriptor 6

Обратите внимание, что интервал очень важен. Если вы поместите пробел между номером fd и символом перенаправления, то exec вернется к исходному значению:

  exec 3 < thisfile       # oops, overwrite the current program with command "3"

Можно использовать несколько способов: ksh использовать read -u или print -u, на bash, например:

read <&3
echo stuff >&4

есть еще одно использование, которое я нашел довольно удобным и стоит упомянуть здесь, потому что оно относится к веб-приложениям на python и кажется чем-то промежуточным между вашими (удивительными) ответами 2 и 3. Обычно я запускаю веб-приложения wsgi (скажем, django или flask) через супервизор, вызывающий gunicorn app: последний, как известно, требует довольно много переменных окружения, он намного проще и удобнее в обслуживании, запускает gunicorn из сценария оболочки, который все настраивает и в итоге exec gunicorn правильный pid супервизору.
В документах сказано, что exec может использоваться для перенаправления:> Если команда не указана, любые перенаправления вступают в силу в текущей оболочке, а статус возврата равен 0. Если есть ошибка перенаправления, возвращаемый статус равен 1. Но как exec действительно работает, чтобы изменить дескриптор файла? Почему именно эта команда выбрана для этой задачи? (Markdown терпит неудачу прямо сейчас?)
@Ray: лучше всего я могу это сделать: pubs.opengroup.org/onlinepubs/009604599/utilities/exec.html . Если вам нужно знать, как это сделать, посмотрите на исходный код оболочки.
Другое использование: Перенаправить весь вывод скрипта в файл журнала exec >.\logfilename.log 2>&1
Да, это означает выполнение команды, указанной в командной строке. Посмотрите переменную @ в man bash . exec заменяет текущую программу новой, опять же, exec -up на страницах руководства.
Соответствующий дополнительный вопрос: stackoverflow.com/questions/41603122/understanding-exec-in-bash
Красиво и аккуратно объяснено при использовании с файловыми дескрипторами !!
Не могли бы вы объяснить exec &> /var/log/userdata.log , когда следуют другие команды, такие как yum install? Мне кажется, что это приводит к выводу команд в файл журнала вместо их выполнения
@Carmageddon: &> является расширением bash (см. man bash ), и ваш пример эквивалентен exec >/var/log/userdata.log 2>&1 . Другими словами, он перенаправляет stdout и stderr в этот файл. Следующие команды будут наследовать эти перенаправления, пока они не будут сброшены, но они будут выполнены.