在unix中，从终端开始的进程（如果是背景的话）可以（通常）不读取或写入终端。在其他情况下，当进程无法读取/写入其终端（或其他文件描述符）时，它只是阻塞，并且一旦读取或写入完成就继续运行。对于后台进程，它接收SIGTTIN或SIGTTOU，默认情况下暂停进程。如果该进程稍后被预先处理，则shell继续它。
为什么这种行为设计得像这样？阻止文件描述符比信号更容易处理，因为它们通常根本不需要特殊处理。在涉及ttys的其他情况下（例如，如果与终端的连接无法处理数据速率），进程就会阻塞。如果一个过程需要知道这一点，它可以检查它是否有前景。当时在这个设计上有任何优势吗？
当然这种行为现在是posix的一部分，所以现在它因“历史原因”而得到修复，但这些历史原因是什么？
答案 0 :(得分：0)
shell生成的进程通常将stdin / stdout / stderr直接连接到终端。这允许进程执行诸如更改终端设置，字体，键盘输入模式等神奇的东西。
因此，如果进程未暂停，他们仍会尝试读取键盘输入。
知道此逻辑的进程可以监听信号，如果背景
则禁用I / O.