Skip to main content
added 364 characters in body
Source Link
Kusalananda
  • 356.6k
  • 42
  • 739
  • 1.1k

The FIFO is opened by the shell, but the opening of it is blocking until the FIFO is opened for writing by some other process. The Since redirections are processed before the execution of the command, the program is therefore not even executed until the shell's open() call returns. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

Which of these is best suited to your situation depends a bit on what's writing to the FIFO at the other end, and how it does the writing.

Third solution involves having the program opening the FIFO when needed.


According to the Rationale section on sh, a shell must set standard input to blocking because...

If the shell did not reset this flag, it would immediately terminate because no input data would be available yet and that would be considered the same as end-of-file.

The FIFO is opened by the shell, but the opening of it is blocking until the FIFO is opened for writing by some other process. The program is therefore not even executed until the shell's open() call returns. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

Which of these is best suited to your situation depends a bit on what's writing to the FIFO at the other end, and how it does the writing.

The FIFO is opened by the shell, but the opening of it is blocking until the FIFO is opened for writing by some other process. Since redirections are processed before the execution of the command, the program is not even executed until the shell's open() call returns. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

Which of these is best suited to your situation depends a bit on what's writing to the FIFO at the other end, and how it does the writing.

Third solution involves having the program opening the FIFO when needed.


According to the Rationale section on sh, a shell must set standard input to blocking because...

If the shell did not reset this flag, it would immediately terminate because no input data would be available yet and that would be considered the same as end-of-file.

added 115 characters in body
Source Link
Kusalananda
  • 356.6k
  • 42
  • 739
  • 1.1k

The FIFO is opened by the shell, but the opening of it is blocking until therethe FIFO is data to readopened for writing by some other process. This The program is therefore not even executed until the shell's open() call returns. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

Which of these is best suited to your situation depends a bit on what's writing to the FIFO at the other end, and how it does the writing.

The FIFO is opened by the shell, but the opening of it is blocking until there is data to read. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

The FIFO is opened by the shell, but the opening of it is blocking until the FIFO is opened for writing by some other process. The program is therefore not even executed until the shell's open() call returns. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.

Which of these is best suited to your situation depends a bit on what's writing to the FIFO at the other end, and how it does the writing.

Source Link
Kusalananda
  • 356.6k
  • 42
  • 739
  • 1.1k

The FIFO is opened by the shell, but the opening of it is blocking until there is data to read. This is documented behaviour for the open() C library function (used by the shell):

O_NONBLOCK

When opening a FIFO with O_RDONLY or O_WRONLY set:

  • If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
  • If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

So the shell is obviously not using O_NONBLOCK when it's opening the FIFO.

Solution:

  1. cat fifo | program

cat reads from the FIFO until end-of-file, then exits.

  1. tail -f fifo | program

tail reads from the FIFO until end-of-file, then hangs around to wait for more until terminated.