为什么`read -t`不能在RHEL的bash中超时?

为什么read -t在RHEL5或RHEL6上从pipe道读取时没有超时?

这里是我的例子,它不会在我的RHEL盒上超时从pipe道读取:

 tail -f logfile.log | grep 'something' | read -t 3 variable 

如果我正确read -t 3应该在3秒后超时?

提前谢谢了。

克里斯

 GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) 

Solutions Collecting From Web of "为什么`read -t`不能在RHEL的bash中超时?"

虽然不是直接回答你的具体问题,你需要运行类似的东西

 read -t 3 variable < <( tail -f logfile.log | grep "something" ) 

以便在流水线完成后新设置的variable值可见。 看看是否按预期超时。


由于您只是使用read作为退出管道的一种方式,所以您不必担心variable的范围。 但是,由于内部缓冲区的原因, grep可能会在没有超时的情况下找到一个匹配项。 你可以使用--line-buffered选项禁用它(至少使用GNU grep ):

 tail -f logfile.log | grep --line-buffered "something" | read -t 3 

如果可用,另一个选项是timeout命令作为read的替代:

 timeout 3 tail -f logfile.log | grep -q --line-buffered "something" 

在这里,我们在3秒后杀死tail ,并以通常的方式使用grep的退出状态。

chepner给出的解决方案应该工作。

解释为什么你的版本不是很简单:当你像你一样构造一个管道时,数据从左到右流过管道。 但是,如果read时间超时,左侧的程序将继续运行,直到他们注意到管道已损坏,而这只有在他们尝试写入管道时才会发生。

一个简单的例子是:

 cat | sleep 5 

五秒钟后,由于sleep会退出,管道将被打破,但是cat仍然会继续运行,直到您按下返回。

在你的情况下,这意味着,直到grep产生一个结果,你的命令将保持运行,尽管超时。

我现在没有一个RHEL服务器来测试你的脚本,但我可以打赌,阅读是超时退出,并应该如此工作。 尝试运行:

 grep 'something' | strace bash -c "read -t 3 variable" 

你可以确认