Setting up pipelines reading from named pipes without blocking in bash

Question

I'm looking to call a subprocess with a file descriptor opened to a given pipe such that the open() call does not hang waiting for the other side of the pipe to receive a connection.

To demonstrate:

$ mkfifo /tmp/foobar.pipe
$ some_program --command-fd=5 5</tmp/foobar.pipe

In this case, some_program is not run until some process has /tmp/foobar.pipe open for write; however, some_program has useful effects even when it isn't receiving commands, so desired behavior is for some_program to be immediately executed.

Mechanisms to do this by exec'ing through an alternate scripting language (python, perl, etc) or a C wrapper which open /tmp/foobar.pipe with the O_NONBLOCK flag are obvious; I'm looking for a pure-bash solution, should one be possible.

Answer 1

The only way I know getting this kind of result is a hack:

mkfifo /tmp/foobar.in
mkfifo /tmp/foobar.out
( cat </tmp/foobar.in ) >/tmp/foobar.out &
some_program --command-fd=5 5</tmp/foobar.out

perhaps this helps :-)

Answer 2

Opening the FD read/write rather than read-only when setting up the pipeline prevents blocking.

To be a bit more specific:

$ mkfifo /tmp/foobar.pipe
$ some_program --command-fd=5 5<>/tmp/foobar.pipe

prevents the undesired blocking behavior, as 5<>/tmp/foobar.pipe opens in RW mode (as opposed to opening in read-only mode as with 5</tmp/foobar.pipe) although O_NONBLOCK is still set. Thanks to waldner on irc://irc.freenode.org/#bash for this pointer.

Answer 3

What language is some_program written in? Unless it is written in shell itself, or is not intended to be aware that it is sometimes connected to a FIFO, then the program should probably deal with the issue. In C or Perl (and probably Python and the rest), you can gain enough control over the open not to block when you open a FIFO.

In general, programs that need to interact accurately with a FIFO need to be aware that they are dealing with a FIFO, especially if they need to interact without blocking unexpectedly,