10

This script:

#!/bin/bash
tmppipe=/tmp/temppipe
mkfifo $tmppipe
echo "test" > $tmppipe
cat $tmppipe
exit

does not terminate. I assume that the cat command is waiting for an EOF from the pipe; how do I send one?

EvgenKo423
  • 103
Benubird
  • 5,912

2 Answers2

13

No, it's

echo test > "$tmppipe" # BTW, you've got the quotes in the wrong places

that hangs. More precisely, it's the shell opening the pipe for writing before running echo.

pipe are inter-process communication mechanisms, they are to be used between processes running concurrently. Here, the open(WR_ONLY) (>) will block until another process does an open in read mode.

echo test > "$tmppipe" &
cat < "$tmppipe"

will work because echo and cat run concurrently.

On Linux, you can get away with:

exec 3<> "$tmppipe" 4< "$tmppipe"
echo test >&3
exec 3>&-
cat <&4

That works because read+write opens (<>) on pipes don't block on Linux, and because the test\n output by echo is small enough to fit in the pipe, so you can do the write and the read sequentially.

It wouldn't work for a larger output like:

exec 3<> "$tmppipe" 4< "$tmppipe"
seq 100000 >&3
exec 3>&-
cat <&4

Because seq would fill up the pipe (64kiB in current versions of Linux) and block until some other process reads data off that pipe, which will never happen because cat won't run until seq has finished.

Note that:

echo test 1<> "$tmppipe"
cat < "$tmppipe"

would not work either because the echo command line would open the pipe, write test and then close the pipe (and then the system would destroy it as there's no file descriptor open to it anymore). So the next cat command line would try to instantiate a new pipe (and block until something opens the fifo file for writing).

Stéphane Chazelas
  • 544,893
  • Position of quotes really doesn't matter in this case, as $tmppipe contains no special characters. I just habitually put quotes around the argument to echo for readability - I'm used to other languages where string literals require quotes, so this way it is visually clear that "test" is a string being echoed. – Benubird Jun 05 '15 at 10:29
  • @Benubird, note that it's not only about special (wildcard) characters, it's also with any character contained in $IFS. Leaving a variable unquoted (unless you have a very good reason to) is bad practice leading to bugs and potential security issues. Quotes in shell have almost an opposite meaning as with other languages. – Stéphane Chazelas Jun 05 '15 at 10:52
  • Great answer, but I was struggling with your second example (exec 3<> "$tmppipe"). As you explained here, cat < "$tmppipe" will never reach EOF because the writer still exists. For it to work properly we need to open separate file descriptors for reading and writing, like so: exec 3<>"$tmppipe" 4>"$tmppipe" 5<"$tmppipe" 3>&- and then close the write descriptor for the duration of reading: exec 4>&-; cat <&5; exec 4>"$tmppipe";. – EvgenKo423 Feb 11 '21 at 14:00
  • @EvgenKo423, you're right. I've now changed the code so cat terminates using a different approach. – Stéphane Chazelas Feb 11 '21 at 14:14
  • Something I don't understand... When cat <&4 is executed, I guess fd 4 gets closed (no need to perform exec 4<&- right?). But it is fd 0 of cat that receives the EOF status and closes. Is fd 4 closed as well because it is a duplicate of fd 0 of cat? Are there still two "synchronized" file descriptors here, or is it in fact the same object with two different labels (0 and 4, valid in their own respective context) pointing at that same object? I mean, why executing exec 3>&- doesn't close fd 4? Because there is still data in the named pipe? – The Quark Nov 02 '21 at 16:00
  • No, fd 4 is not closed. The fd 0 (and 4, both pointing to the reading end of the pipe) of the process that executes cat are only getting closed when cat exits. In the parent shell process, nothing changed with the fd 4. The pipe that was instantiated upon first opening the fifo file is still there, but there's nothing left in it (as cat consumed everything), and there's no writer left, so a subsequent read on it will still return nothing (EOF). If, until that fd is closed something opens the fifo file, they will still land onto that same pipe. After, an open would instantiate a new pipe. – Stéphane Chazelas Nov 02 '21 at 17:42
2

Turns out the answer is obvious - the pipe is being locked by echo, and never reaches cat!

Pipes do not store data. When a process attempts to write to a pipe, the write cannot complete until there is something attached to the other end of the pipe, to read it.

A way to solve this particular example, is to use

echo "test" > $tmppipe &

to make the writing process run in the background. That way it sits there any waits, while the script continues, until it reaches the cat and can complete.

Benubird
  • 5,912
  • Strictly speaking, pipes store a buffer-full of data (the contenance of the pipe as in a real-life pipe), but pipes only live as long as there are file descriptors open to them. For fifo files, pipes are intentiated only when both a fd for reading and one for writing have been open to the file (or one fd in read+write on some systems), subsequent opens (of the same fifo file) while that pipe is active reuse the same pipe. Note that here, it's not writing to the pipe that blocks, but open it first (before running echo) – Stéphane Chazelas Jun 05 '15 at 10:27