CODEWITHSUNDEEP
shellnamed-pipesio-redirection
puk
puk

Reputation: 16782

Can't redirect multiple shell statements to named pipe

Observe what happens when I issue two commands one after another, as opposed to on a single line, separated by a semicolon:

Make pipe and launch movie:

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

Exit Trial 1:

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

Exit Trial 2:

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

Exit Trial 3:

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

Could someone provide an explanation of why trial 2 does nothing. Also, is there a better way of issuing the quit command via the named pipe which does not require two echo statements?

Upvotes: 0

Views: 363

Answers (3)

jehutting
jehutting

Reputation: 21

omxplayer is a little bit picky on its (command) input. It doesn't like a command (e.g. q ) to be terminated with a newline '\n'. A newline will be incorrectly handled by making it a part of the command ('q''\n'), resulting in an unknown command (whereas only 'q' exists as a valid command). Hence, the -n option is necessary when echo-ing commands to omxplayer.

Apart from this 'erroneous handling' of omxplayer, the same behavior can be seen when using cat pipe1 | cat in stead. After killing the second cat it is the last (or first following) echo which terminates the first cat.

Upvotes: 1

user2719058
user2719058

Reputation: 2233

If the last writer on the fifo dies and the reader checks the fifo, it sees an end-of-file. If there is again a new writer before the reader checks, there is no end-of-file seen by the reader. I guess your reader (omxplayer) checks for end-of-file.

To put it from the perspective of the reader omxplayer: it sees

  1. "q" EOF ... <LF> EOF
  2. "q" (EOF probably not seen by omxplayer) <LF> EOF
  3. "q" EOF ... <LF> EOF

What happens is entirely up to how omxplayer processes this, and not a matter of you, the operating system or your shell messing it up.

Upvotes: 2

chepner
chepner

Reputation: 531165

I suspect buffering is involved somehow. Both (1) and (3) provide some relatively long period of time between the q and the linefeed, stopping the movie but not exiting until it has read a full line. In (2), the q and linefeed are so close together, that perhaps omxplayer is just ignoring the entire string. What does echo q > pipe1 (which is similar to (2), but even faster) do?

Upvotes: 1

Related Questions