0

观察当我一个接一个地发出两个命令时会发生什么，而不是在一行上，用分号分隔：

制作管道并启动电影：

$ mkfifo pipe1
$ tail -f /dev/null > pipe1 &
$ cat pipe1 | omxplayer /path/to/video.mp4

退出试验一：

$ echo -n q > pipe1; # Exits movie, but omxplayer hangs
$ echo > pipe1; # Completes exit process

退出试验 2：

$ echo -n q > pipe1; echo > pipe1 # Does nothing

退出试验 3：

$ echo -n q > pipe1; sleep 1; echo > pipe1 # Works just like trial 1

有人可以解释为什么试验 2 什么都不做。另外，有没有更好的方法通过不需要两个echo语句的命名管道发出退出命令？

4

3 回答 3

2

如果 fifo 上的最后一个 writer 死了，而 reader 检查了 fifo，它会看到一个文件结尾。如果在阅读器检查之前再次有新的写入器，则阅读器看不到文件结尾。我猜你的阅读器（omxplayer）会检查文件结尾。

从读者的角度来说omxplayer：它看到了

  1. "q" EOF ... <LF> EOF
  2. "q"（EOF可能没见过omxplayer）<LF> EOF
  3. "q" EOF ... <LF> EOF

发生的事情完全取决于如何omxplayer处理它，而不是你、操作系统或你的 shell 把它搞砸了。

于 2013-11-12T21:30:27.710 回答
1

我怀疑以某种方式涉及缓冲。(1) 和 (3) 都在 和 换行之间提供了一些相对较长的时间段q，停止电影但直到读完一整行才退出。在 (2) 中，theq和 linefeed 非常接近，可能omxplayer只是忽略了整个字符串。echo q > pipe1（类似于（2），但更快）做什么？

于 2013-11-12T21:11:17.837 回答
1

omxplayer 对其（命令）输入有点挑剔。它不喜欢q以换行符终止的命令（例如）'\n'。通过将换行符作为命令 ( ) 的一部分，将错误地处理换行符'q''\n'，从而导致未知命令（而仅'q'作为有效命令存在）。因此，-n当echo-ing 命令到omxplayer.

除了对 的这种“错误处理”之外，在替代omxplayer使用时可以看到相同的行为。cat pipe1 | cat在杀死第二个 cat之后，它是最后一个（或第一个跟随者）echo终止第一个 cat。

于 2014-02-09T06:25:07.927 回答