Misunderstand line-buffer in Unix

The point behind the machinations described is to ensure that prompts appear before the system goes into a mode where it is waiting for input.

If an input stream is unbuffered, every time the standard I/O library needs data, it has to go to the kernel for some information. (That's the last sentence.) That's because the standard I/O library does not buffer any data, so when it needs more data, it has to read from the kernel. (I think that even an unbuffered stream might buffer one character of data, because it would need to read up to a space character, for example, to detect when it has reached the end of a %s format string; it has to put back (ungetc()) the extra character it read so that the next time it needs a character, there is the character it put back. But it never needs more than the one character of buffering.)

If an input stream is line buffered, there may already be some data in its input buffer, in which case it may not need to go to the kernel for more data. In that case, it might not flush anything. This can occur if the scanf() format requested "%s" and you typed hello world; it would read the whole line, but the first scan would stop after hello, and the next scanf() would not need to go to the kernel for the world word because it is already in the buffer.

However, if there isn't any data in the buffer, it has to ask the kernel to read the data, and it ensures that any line-buffered output streams are flushed so that if you write:

printf("Enter name: ");if (scanf("%63s", name) != 1)    …handle error or EOF…

then the prompt (Enter name:) appears. However, if you'd previously typed hello world and previously read just hello, then the prompt wouldn't necessarily appear because the world was already waiting in the (line buffered) input stream.

This may explain the point.

Let's imagine that you have a pipe in your program and you use it for communication between different parts of your program (single thread program writing and reading from this single pipe).

If you write to the writing end of the pipe, say the letter 'A', and then call the read operation to read from the reading end of the pipe. You would expect that the letter 'A' is read. However, read operation is a system call to the kernel. To be able to return the letter 'A' it must be written to the kernel first. This means that the writing of 'A' must be flushed, otherwise it would stay in your local writing buffer and your program would be locked forever.

In consequence, before calling a read operation all write buffers are flushed. This is what the section (b) says.

The size of the buffer that the standard I/O library is using to collect each line is fixed.

with the help of the fgets function we are getting the line continuously, during that time it will read the content with the specified buffer size or up to newline.

Second, whenever input is requested through the standard I/O library, it can use an unbuffered stream or line-buffered stream.

unbuffered stream - It will not buffer the character, flush the character regularly.

line-buffered - It will store the character into the buffer and then flush when the operation is completed.

lets take without using \n we are going to print the content in printf statement, that time it will buffer all the content until we flush or printing with new line. Like that when the operation is completed the stream buffer is flushed internally.

(b) is that the requested data may already be in the buffer, which doesn't require data to be read from the kernel

In line oriented stream the requested buffer may already in the buffer because the data can be buffered, so we can't required data to read from the kernel once again.

(a) requires data to be obtained from the kernel.

Any input from unbuffered stream item, a data to be get from the kernel due to the unbuffered stream can't store anything in the buffer.