我读了一个声称正在运行的用户的答案
foo 2>&1 >& output.log &
foo即使他们注销，也会导致继续运行。据该用户称，这甚至可以通过 SSH 连接工作。
我并不真正相信这一点，因为我的印象是，在与 SSH 断开连接或终止 TTY 的情况下，shell 及其进程会收到 SIGHUP，导致它们终止。这一点，我的假设下，被使用的唯一理由nohup在这样的情况下，或者tmux，screen等。
然后我查看了glibc 的手册：
该信号还用于向与该会话相关联的作业报告终端上控制进程的终止；此终止有效地断开会话中的所有进程与控制终端的连接。
这似乎证实了我的想法。但进一步看，它说：
如果进程是具有控制终端的会话领导者，则向前台作业中的每个进程发送 SIGHUP 信号，并且控制终端与该会话解除关联。
那么，这是否意味着置于后台的作业将不会收到 SIGHUP？
令我更加困惑的是，我运行了一个交互式 Zsh 会话，运行yes >& /dev/null &并输入了exit，当 Zsh 警告我有正在运行的作业时，exit第二次输入后，它告诉我它已经 SIGHUPed 一个作业。在 Bash 中执行完全相同的操作会使工作继续运行……
处理几个文件的常用方法是——不要为此打我：
for f in $(ls); do …
现在，为了防止带有空格或其他奇怪字符的文件，一种天真的方法是：
find . -type f -print0 | while IFS= read -r -d '' file; …
在这里，-d ''是设置 ASCII NUL 的缩写，如-d $'\0'。
但为什么会这样呢？为什么是''和$'\0'一样？这是因为 Bash 的 C 根以空字符串总是以空字符结尾吗？
我们有一台运行 VMware Server 的机器。它不断创建一个名为not_configuredin的文件/etc/vmware/，这以某种方式使我们的虚拟机无法启动。
我想知道是否有任何可靠的方法可以防止从一开始就创建此文件。
文件本身不包含任何内容，所以我不想创建和写保护它。它首先不应该在那里。