If I understand correctly, an EOF is created there when the first process ends, causing the handset to close.
Grade. There is a little more than this - it is technically incorrect to say that the pipe closes as soon as the first process ends.
Instead, channels and FIFOs return EOF when there is no more data in the channel and it is not opened for recording by any process.
This is usually permitted when the read process opens FIFO for both reading and writing, even if it never writes - for example, a server that accepts local clients by reading from FIFO can open FIFO for reading and writing so that when with no active clients, the server did not have to deal with a special case of EOF. This is the “standard” way to deal with it, as described in Advanced Programming in UNIX in the chapter on IPC mechanisms.
In your case, this is impossible, because you do not have a permanent process that continues to work (i.e. you do not have the equivalent of a server process). You basically need some kind of "permanent writer", i.e. A process that supports a channel that is open for recording during various iterations.
One solution that I can think of is cat standard input in FIFO in the background. This ensures that cat opens FIFO for writing, so there is always an active writer, but by saving it in the background, you don’t actually feed it with any input and you never write to FIFO. Just keep in mind that the task will be stopped (but not completed) by the shell as soon as cat tries to read from stdin (processes running in the background process are usually sent by SIGTTIN and stop when they try to read from stdin because they don’t have a manager terminal until they are brought to the fore). In any case, until you submit any data, you are kind - the process is in a stopped state, but the FIFO is still open for writing. You will never see EOF on the pipe if the background job is not completed.
So, in short, you:
- Create a FIFO:
mkfifo /home/pipe - Run a background job that opens FIFO for writing:
cat >/home/pipe & - Run your programs as much as you want, how many iterations you want. Ignore the shell message about the stopped background job. You can simply leave it like this, since the tube is still open for recording, even if the job is stopped.
- When you're done, kill the
cat background, either by bringing it to the foreground and sending it SIGINT (usually Ctrl + C) or using kill PID .
Please note that in this case the reading process (mysql in this case) will never know when the input is finished. It will always block more input unless you kill the background cat before you kill mysql.