为什么expect使流程开放它'；什么是标准？

我想为进程设置超时，这是我的shell。 我使用expect来做这件事，以避免其他包的依赖性

test.sh

#!/bin/bash
# $1 timeout in seconds
# $2 command
timeout() {
        time=$1
        shift
        # start the command in a subshell to avoid problem with pipes
        # (spawn accepts one command)                            -noecho 
        command="/bin/sh -c \"$*\""
        expect -c "set echo \"-noecho\";set timeout $time; spawn -noecho $command; expect timeout { exit 1 } eof { exit 0 }"
        if [ $? = 1 ] ; then
            echo "timeout after ${time} seconds"
            exit 1
        fi

}

timeout 120 ./test

test.c

#include <stdlib.h>
int main() {
    sleep(120);
}

这是expect，它继承了父（我的shell）管道，并打开14070167管道以捕获休眠程序test.c（我猜它是管道子的STDOUT）

但让我困惑的是test.c并没有将1复制到管道[140167]。到目前为止，它工作得很好。（然而，这不是导致问题的原因）

但是我有一个BUG，如果test.c是一个守护进程程序，它会得到fd5，即管道14070158（这是test.sh STDERR之前复制过的）。在expect退出之后。如果我轮询test.sh的STDERR，它将阻塞，因为发送方端口是一个守护程序。（假设test.c是该守护程序）

我的问题是expect如何工作？我可以让它不把管道[14070158]交给test.c来修复我的BUG吗

---

我的expect版本是5.43

它看起来像expect为其子进程分配了一个PTY来与之交互（例如，

screen

does）。然而，我不明白这是如何给您带来问题的，您所说的“如果我为test.sh轮询STDERR，它将阻塞”是什么意思？@Krumelur问题是test.c的fd 5管道[140705158]。假设test.c是一个守护进程，我的进程轮询管道（执行fork&exec的进程），它将阻塞，因为test.c获取或继承了我认为不应该在test.c中打开的管道。这导致我的进程被阻塞。您是否在使用STDERR进行某种IPC？或者为什么你的守护进程关心STDERR？@Krumelur我想应该是dup STDERR for daemon（fd5），这会使守护进程有一个匿名fd。根本不回答你问题的细节：既然你已经标记了，为什么不使用

lrwx------ 1 root root 64 Sep 13 17:07 0 -> /dev/pts/1
l-wx------ 1 root root 64 Sep 13 17:07 1 -> pipe:[14070157]
l-wx------ 1 root root 64 Sep 13 17:07 2 -> pipe:[14070158]
lr-x------ 1 root root 64 Sep 13 17:07 255 -> /path/to/my/shell

lrwx------ 1 root root 64 Sep 13 17:08 0 -> /dev/pts/1
l-wx------ 1 root root 64 Sep 13 17:08 1 -> pipe:[14070157]
l-wx------ 1 root root 64 Sep 13 17:07 2 -> pipe:[14070158]
lr-x------ 1 root root 64 Sep 13 17:08 3 -> pipe:[14070167]
l-wx------ 1 root root 64 Sep 13 17:08 4 -> pipe:[14070167]
lrwx------ 1 root root 64 Sep 13 17:08 5 -> /dev/tty
lrwx------ 1 root root 64 Sep 13 17:08 6 -> /dev/ptmx

lrwx------ 1 root root 64 Sep 13 17:07 0 -> /dev/pts/2
lrwx------ 1 root root 64 Sep 13 17:07 1 -> /dev/pts/2
lrwx------ 1 root root 64 Sep 13 17:07 2 -> /dev/pts/2
lr-x------ 1 root root 64 Sep 13 17:07 3 -> pipe:[14070167]
l-wx------ 1 root root 64 Sep 13 17:07 4 -> pipe:[14070167]
l-wx------ 1 root root 64 Sep 13 17:07 5 -> pipe:[14070158]