Как “правильно” запустить приложение от оболочки

Есть несколько способов выполнить программу и отсоединить ее от терминала. Один из них - запустить его в фоновом режиме подоболочки , например (замените firefox своей любимой программой):

(firefox &)

Другой - отказаться от процесса:

firefox & disown firefox

Если вы интересно узнать, как работают средства запуска приложений, dmenu предоставляет 1 двоичный и 2 сценария оболочки: dmenu , dmenu_path и dmenu_run , соответственно.

dmenu_run перенаправляет вывод dmenu_path в dmenu, который, в свою очередь, перенаправляет во все, что установлено вашей переменной $ SHELL . Если он пуст, он будет использовать / bin / sh .

#!/bin/sh
dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &

dmenu_path немного сложнее, но вкратце он предоставляет список двоичных файлов в вашей переменной среды $ PATH и, если возможно, использует кеш.

#!/bin/sh
cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
if [ -d "$cachedir" ]; then
        cache=$cachedir/dmenu_run
else
        cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
fi
IFS=:
if stest -dqr -n "$cache" $PATH; then
        stest -flx $PATH | sort -u | tee "$cache"
else
        cat "$cache"
fi

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

#!/bin/sh
$(dmenu_path | dmenu "$@") &

Мне очень нравится ответ G -Мана. Но я отвечаю, потому что я думаю, что вы путаете проблемы. Как отмечает Уэйн, лучший ответ — «все, что дает желаемые результаты».

В системе управления процессами Unix у каждого процесса есть родитель. Единственным исключением является процесс init, который запускается ОС при загрузке. Это нормальное поведение для родительского процесса, когда он умирает, забирая с собой все свои дочерние процессы. Это делается путем отправки сигнала SIGHUP всем дочерним процессам; обработка SIGHUP по умолчанию завершает процесс.

Порождение оболочки пользовательских процессов ничем не отличается от того, как если бы вы закодировали вызовы fork (2)/ exec (3)на выбранном вами языке. Оболочка является вашим родителем, и если оболочка завершается (, например, вы выходите из системы ), то дочерний процесс (es ), который она порождает, уходит вместе с ней. Описанные вами нюансы — это всего лишь способы изменить это поведение.

exec /path/to/programподобен вызову exec (3). Да, он заменит вашу оболочку на program, сохранив тот родитель, который запустил оболочку.

sh -c /path/to/programбессмысленно создает дочерний процесс оболочки, который создаст дочерний процесс program. Это ценно только в том случае, если /path/to/programна самом деле является последовательностью инструкций скрипта, а не исполняемым файлом.(sh /path/to/script.sh может использоваться для запуска сценария оболочки, которому не хватает разрешений на выполнение в подчиненной оболочке)

/path/to/programсоздает процесс «переднего плана», что означает, что оболочка ожидает завершения процесса, прежде чем предпринимать какие-либо другие действия. В контексте системного вызова это похоже на fork (2)/ exec (3)/ waitpid (2). Обратите внимание, что потомок наследует stdin/stdout/stderr от родителя.

/path/to/program &(игнорирование перенаправления )создает "фоновый процесс". Процесс по-прежнему является дочерним по отношению к оболочке, но родитель не ждет его завершения.

nohup /path/to/programвызывает nohup (1 ), чтобы предотвратить отправку SIGHUP на program, если управляющий терминал закрыт. На переднем плане или на заднем – это выбор (, хотя чаще всего этот процесс выполняется в фоновом режиме ). Обратите внимание, что nohup.outявляется выводом только в том случае, если вы не перенаправляете стандартный вывод.

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

Когда вы перенаправляете ввод/вывод/ошибку, вы просто связываете файловые дескрипторы, которые есть у каждого процесса, с файлами, отличными от тех, которые он наследует от своего родителя. Ничто из этого не влияет на владение процессом или глубину дерева (, но всегда имеет смысл перенаправить все 3 от терминала для фоновых процессов ).

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