Question

Consider the following scenario:

a FIFO named test is created. In one terminal window (A) I run cat <test and in another (B) cat >test. It is now possible to write in window B and get the output in window A. It is also possible to terminate the process A and relaunch it and still be able to use this setup as suspected. However if you terminate the process in window B, B will (as far as I know) send an EOF through the FIFO to process A and terminate that as well.

In fact, if you run a process that does not terminate on EOF, you’ll still not be able to use your FIFO you redirected to the process. Which I think is because this FIFO is considered closed.

Is there anyway to work around this problem?

The reason to why I ran into this problem is because I’d like to send commands to my minecraft server running in a screen session. For example: echo "command" >FIFO_to_server. This is problably possible to do by using screen by itself but I’m not very comfortable with screen I think a solution using only pipes would be a simpler and cleaner one.

Answer 1

A is reading from a file. When it reaches the end of the file, it stops reading. This is normal behavior, even if the file happens to be a fifo. You now have four approaches.

1. Change the code of the reader to make it keep reading after the end of the file. That’s saying the input file is infinite, and reaching the end of the file is just an illusion. Not practical for you, because you’d have to change the minecraft server code.

2. Apply unix philosophy. You have a writer and a reader who don’t agree on protocol, so you interpose a tool that connects them. As it happens, there is such a tool in the unix toolbox: tail -f. tail -f keeps reading from its input file even after it sees the end of the file. Make all your clients talk to the pipe, and connect tail -f to the minecraft server:

   tail -n +1 -f client_pipe | minecraft_server &
   

3. As mentioned by jilles, use a trick: pipes support multiple writers, and only become closed when the last writer goes away. So make sure there’s a client that never goes away.

   while true; do sleep 999999999; done >client_pipe &
   

4. The problem is that the server is fundamentally designed to handle a single client. To handle multiple clients, you should change to using a socket. Think of sockets as “meta-pipes”: connecting to a socket creates a pipe, and once the client disconnects, that particular pipe is closed, but the server can accept more connections. This is the clean approach, because it also ensures that you won’t have mixed up data if two clients happen to connect at the same time (using pipes, their commands could be interspersed). However, it require changing the minecraft server.