I have this command:

ql_receiver_lock_holder > "${my_named_pipe}"

will it overwrite the named pipe if it already exists? Is the best way to avoid overwriting it to simply use this:

ql_receiver_lock_holder >> "${my_named_pipe}"

2 Answers 2


Redirecting into a named pipe will not remove the pipe, it will pass the data through the pipe, or block if nothing is reading from the pipe.

This the normal way of using a named pipe. You create it, and then you send data through it.


> does a open() in O_WRONLY|O_TRUNK mode while >> does a open() in O_WRONLY|O_APPEND mode, but for a named pipe, that makes no difference.

3 different cases to consider:

  1. no process has opened the fifo file for reading yet: then the open() (which is done by the shell before the command is even executed) will block until some process opens the file for reading.
  2. some process has already opened the fifo file for reading, but none for writing yet: then our open() will succeed and instantiate the pipe. Then, the command will be started straight away and will be able to write to the pipe where the data will accumulate until the pipe gets full or some process reads the content at the other end.
  3. the pipe has already been instantiated (because the fifo file has already been opened both for reading and writing). Then the open() will return a fd to that same pipe (not instantiate a new one). That means the writes that our command does will be interleaves with those of other commands writing to the pipe. Writes are only guaranteed to be atomic if smaller that PIPE_BUF (4KiB on Linux). That's no different from regular pipes as created by pipe()

An opening mode that makes a difference is O_RDWR (read+write) which in shells you achieve with the <> operator (1<> to redirect stdout, as otherwise it opens on fd 0 (stdin)), which on many systems never blocks and instantiates the pipe if not already instantiated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .