Пример использования / практический пример для встроенного в Bash exec

Учтите это из документации встроенного в Bash exec:

exec заменяет оболочку без создания нового процесса

Пожалуйста, предоставьте пример использования / практический пример. Я не понимаю, как это имеет смысл.

Я гуглил и нашел про перенаправление ввода / вывода . Вы можете объяснить это лучше?

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

#!/bin/sh

if stuff;
    EXTRA_OPTIONS="-x -y -z"
else
    EXTRA_OPTIONS="-a foo"
fi

exec /usr/local/bin/the.real.binary $EXTRA_OPTIONS "$@"

так что после завершения работы оболочки «настоящий» двоичный файл вступает во владение, и больше не остается никаких следов сценария оболочки, который временно занимал тот же слот в таблице процессов. «Настоящий» двоичный файл является прямым потомком того, что его запустило вместо внука.

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

exec 3>>/tmp/logfile

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

Я использовал execвстроенную оболочку, чтобы получить идентификатор процесса (PID) для Java-программы. Возможно, сейчас есть способ получить PID изнутри Java, но несколько лет назад его не было. Как только у процесса есть свой собственный PID, он может записать его в файл PID (искать /var/run/имена файлов с суффиксом «.pid»), чтобы позволить управляющим программам узнать PID запущенного процесса и предотвратить второй экземпляр. того же сервера от запуска. Это работает примерно так:

exec java -cp=YourServer.jar StartClass -p $$

Код в main()методе класса StartClassобрабатывает разбор аргументов и может найти свой собственный идентификатор процесса.

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

while(true) fork();

Теперь, когда каждый слот в таблице процессов, который вам разрешено использовать, заполнен копиями этой запущенной программы, как вы собираетесь его убить? Для запуска kill (1) требуется еще один слот процесса, которого у вас нет. Конечно, было бы удобно, чтобы оболочка заменила себя командой kill ...

exec /bin/kill -9 -1

(Предполагается, что ваша система имеет kill (1) в / bin / kill. "Exec` which kill` -9 -1 "потенциально безопаснее.) Это отправляет SIGKILL каждому процессу, который вы можете.

(Примечание: не выходите из своей запускающей оболочки, если ограничения процесса не всегда разрешают новый вход в слот процесса для его оболочки. Это может быть немного сложнее очистить, если вы это сделаете. Я, конечно, не делал этого в начало 90-х. Нет.)

• Это похоже на пример Брюса о необходимости знать PID процесса:

  (cmdpid = $ BASHPID; (сон 300; kill "$ cmdpid") & exec long-running-command )

  в котором ты

  1. Запустить подоболочку (внешнюю (и )),
  2. Узнайте PID подоболочки. ( $$даст вам PID основной оболочки.)
  3. Отсоедините вложенную оболочку, которая убивает ваш процесс после истечения времени ожидания, и
  4. Запустите команду в процессе подоболочки, которую вы создали в шаге 1.

  Это будет выполняться long-running-command, но только в течение заранее определенного, ограниченного периода времени. 

• Это немного несерьезно, но, если вы решите, что хотите быть суперпользователем (или другим пользователем) до конца сеанса входа в систему, вы можете это сделать exec su.

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

  Вы сделали то, что хотели, и готовы выйти из системы. Ваш друг Боб находится в комнате с вами, и он хочет сделать некоторую работу с удаленной системой - но он не сможет подключиться. Итак, вы печатаете exec su - bobи, когда появляется запрос пароля, передаете рабочую станцию ​​ему. Теперь нет никакого процесса с вашим UID (если вы не запустили что-то в фоновом режиме), поэтому Боб не сможет возиться с вашими файлами. Он будет эффективно завладеть вашей связью (с вашего согласия и сотрудничества).

  Примечания:

  • Конечно, это не сработает, если вам не разрешено бежать su.
  • Он будет зарегистрирован, поэтому вам может понадобиться объяснить ваши мотивы кому-то. Поскольку вы обходите политику (расписание брандмауэра), у вас могут возникнуть проблемы.
  • Я не гарантирую, что это на 100% безопасно. Например, whoвероятно все равно покажет ваше имя. Вполне возможно, что некоторые (плохо написанные) программы будут использовать это, чтобы думать, что Боб - это вы, и дать ему доступ к вашим ресурсам.
  • Если система выполняет аудит, действия Боба могут проверяться под вашим именем.