named pipes to Unix
I read about them for a long time, even when I was learning the basics of Unix, but somehow there was no need to work with them. And, here, the need arose.
A certain program (say, foo) cannot write output to stdout, only to a file. Even "-" as a file name only creates a file called "-" [most smart programs under unix know that a single minus instead of a file name means output to stdout]. Similarly, it rejects / dev / stdout.
The other program that processes the results of the first, say, bar, reads from stdin and writes to stdout. (To be precise, the first is a special kind of tracer, giving a binary dump, and the second is a converter that prints them in human-readable form).
')
It is necessary to unite them in a conveyor.
Ugly option - use a regular file. Recorded, read.
There is a much more beautiful option - it is named pipes . Since the pipe has a name, we can transfer it as a file to the first program, and then transfer the contents to another.
It looks like this:
The file system pipe looks like this:
(emphasis on the letter 'p' by the first character).
How it works? In fact, the aka named pipe fifo is an “ordinary pipe”, like the one that is encoded with the “|” stick. However, he has a NAME and this name can be entered wherever a file is required.
A program that writes to a named pipe behaves as if it were a file. Those. writes himself and writes. A program that reads is similar. Reads himself and reads. The reading is in the order in which it was written (FIFO - first in first out). The provisions regarding the pipe (left / right) are determined by those who read and who write.
The important peculiarity of the pipe is the ability to slow down the reading / squeaking program if the buffer is empty / full.
Consider the example of reading. The program writes one line per second to the pipe. The reading program reads as fast as possible. The program "reads" everything that was in the buffer, and sends the following request. The kernel delays this request until the data is displayed. Thus, it is possible not to bathe with synchronization - data will appear, the program-processor will receive control back from read () and will process the next portion of data.
A certain program (say, foo) cannot write output to stdout, only to a file. Even "-" as a file name only creates a file called "-" [most smart programs under unix know that a single minus instead of a file name means output to stdout]. Similarly, it rejects / dev / stdout.
The other program that processes the results of the first, say, bar, reads from stdin and writes to stdout. (To be precise, the first is a special kind of tracer, giving a binary dump, and the second is a converter that prints them in human-readable form).
')
It is necessary to unite them in a conveyor.
Ugly option - use a regular file. Recorded, read.
There is a much more beautiful option - it is named pipes . Since the pipe has a name, we can transfer it as a file to the first program, and then transfer the contents to another.
It looks like this:
mkfifo mypipe cat mypipe | bar & foo mypipe & rm mypipe
The file system pipe looks like this:
ls -l mypipe prw-r - r-- 1 root root 0 May 24 12:23 mypipe
(emphasis on the letter 'p' by the first character).
How it works? In fact, the aka named pipe fifo is an “ordinary pipe”, like the one that is encoded with the “|” stick. However, he has a NAME and this name can be entered wherever a file is required.
A program that writes to a named pipe behaves as if it were a file. Those. writes himself and writes. A program that reads is similar. Reads himself and reads. The reading is in the order in which it was written (FIFO - first in first out). The provisions regarding the pipe (left / right) are determined by those who read and who write.
The important peculiarity of the pipe is the ability to slow down the reading / squeaking program if the buffer is empty / full.
Consider the example of reading. The program writes one line per second to the pipe. The reading program reads as fast as possible. The program "reads" everything that was in the buffer, and sends the following request. The kernel delays this request until the data is displayed. Thus, it is possible not to bathe with synchronization - data will appear, the program-processor will receive control back from read () and will process the next portion of data.
Source: https://habr.com/ru/post/94350/
All Articles