如何从 shell“正确”启动应用程序

Question 1

有几种方法可以执行程序并将其与终端分离。一种是在后台运行一个子shell的，像这样（替换firefox为您最喜欢的程序）：

(firefox &)

另一种是否认这个过程：

firefox & disown firefox

如果您对应用程序启动器的工作原理感到好奇，请分别dmenu提供 1 个二进制文件和 2 个 shell 脚本：dmenu、dmenu_path和dmenu_run。

dmenu_run将的输出通过管道传输dmenu_path到 dmenu，而 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

没有必要让程序在 shell 中运行。另一种无需通过管道传输到 shell 的编写方法dmenu_run是：

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

Answer

有几种方法可以执行程序并将其与终端分离。一种是在后台运行一个子shell的，像这样（替换firefox为您最喜欢的程序）：

(firefox &)

另一种是否认这个过程：

firefox & disown firefox

如果您对应用程序启动器的工作原理感到好奇，请分别dmenu提供 1 个二进制文件和 2 个 shell 脚本：dmenu、dmenu_path和dmenu_run。

dmenu_run将的输出通过管道传输dmenu_path到 dmenu，而 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

没有必要让程序在 shell 中运行。另一种无需通过管道传输到 shell 的编写方法dmenu_run是：

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

Question 2

我非常喜欢G-Man的回答。但我之所以做出回应，是因为我认为你的担忧令人困惑。正如韦恩指出的，最好的答案是“无论什么都能得到你想要的结果”。

在Unix进程管理中，每个进程都有一个父进程。唯一的例外是init操作系统在启动时启动的进程。父进程在死亡时带走所有子进程是正常行为。这是通过向所有子进程发送 SIGHUP 信号来完成的； SIGHUP 的默认处理会终止进程。

用户进程的 shell 生成与您编写的代码没有什么不同叉子(2)/执行(3)以您选择的语言进行通话。 shell 是您的父进程，如果 shell 终止（例如，您注销），那么它生成的子进程也会随之消失。您描述的细微差别只是修改该行为的方法。

exec /path/to/program就像打电话执行(3)。是的，它会将您的 shell 替换为program，保留任何父级启动的 shell。

sh -c /path/to/program有点毫无意义地创建一个子 shell 进程，该进程将创建program.仅当/path/to/program它实际上是一系列脚本指令而不是可执行文件时才有价值。（sh /path/to/script.sh可用于在劣质 shell 中运行缺乏执行权限的 shell 脚本）

/path/to/program创建一个“前台”进程，这意味着 shell 会等待该进程完成，然后再执行任何其他操作。在系统调用上下文中，它就像叉子(2)/执行(3)/等待进程(2)。请注意，子进程从父进程继承 stdin/stdout/stderr。

/path/to/program &（忽略重定向）创建一个“后台进程”。该进程仍然是 shell 的子进程，但父进程并不等待它终止。

nohup /path/to/program调用诺哈普(1)program如果控制终端关闭，则阻止发送 SIGHUP 。无论是在前台还是后台都是一个选择（尽管最常见的是该进程是后台的）。请注意，如果您不以其他方式重定向标准输出，则这nohup.out只是输出。

当您将进程置于后台时，如果父进程终止，则会发生以下两种情况之一。如果父母是控制终端，然后 SIGHUP 将发送给孩子们。如果不是，则该进程可能是“孤立的”，并由该init进程继承。

当您重定向输入/输出/错误时，您只需将每个进程拥有的文件描述符连接到与从其父进程继承的文件不同的文件。这些都不会影响进程所有权或树深度（但将所有 3 个进程从终端重定向到后台进程总是有意义的）。

话虽如此，我认为您不应该关心 shell 或子 shell 或子进程的进程创建，除非您正在解决与进程管理相关的特定问题。

Answer