c - shell脚本中的后台进程收到EOF

Question

很难解释这种行为，所以这里有一个可重现的例子(在 macOS 上测试过)。

首先，我有以下 C 文件。细节并不重要，但我基本上使用了 read system call从标准输入读取 16 个字节，或者直到遇到 EOF。请注意，read 将在 EOF 处返回 0。

// test.c

#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int main() {
    char buf[1];
    for (int i = 0; i < 16; i++) {
        if (read(STDIN_FILENO, buf, 1) == 0) {
            printf("EOF encountered! Number of bytes read: %d\n", i);
            return 0;
        }
    }
    printf("Read all 16 bytes\n");
    return 0;
}

假设我将这个文件编译成一个名为test 的二进制文件。这是正在运行的程序:

$ echo 'sixteen bytes!!' | ./test
Read all 16 bytes

$ echo '' | ./test
EOF encountered! Number of bytes read: 1

$ ./test # Waits for user input

有道理吗？我什至可以接受最后一条命令并将其作为后台进程运行(尽管这毫无用处):

$ ./test &
[1] 19204

[1]  + suspended (tty input)  ./test

假设我接受这条命令并将其放入以下 ​​shell 脚本(称为 huh.sh):

#!/bin/sh

./test &

当我运行这个 shell 脚本时，输出如下:

$ ./huh.sh

EOF encountered! Number of bytes read: 0

这意味着 read 立即遇到 EOF，并且这只发生在 shell 脚本的上下文中。

如果我将 test 替换为另一个对 EOF 敏感的程序，我会看到类似的行为。例如，如果我直接在终端中运行 node &，我将能够在 ps 的输出中看到 node 进程.但是，如果我在 shell 脚本中运行 node &，它会立即退出。

谁能解释一下？

Answer 1

作业控制在交互式 shell 中默认启用，但在 shell 脚本中默认禁用。这是一个相关的引用from POSIX :

If job control is disabled (see set, -m), the standard input for an asynchronous list, before any explicit redirections are performed, shall be considered to be assigned to a file that has the same properties as /dev/null. This shall not happen if job control is enabled.