>>133
Look, you do see what is the difference between cat(1) and read(1), correct? Every character is checked so the newline can be found and be written immediately. When the output is piped to another process, it'll be able to process that line directly. Another program, for instance cat(1) would sometimes wait until an 8k buffer is filled or EOF before writing anything. That is inconsequential for batch processing, but bad for interactive use. Then you want your line as soon as it's available.
You're getting hung up on the "single write" in the man page, and read too much into it. A program that read and wrote a single character at a time could be used for the same purpose as read(1). The line would be available straight away. The only difference is that read(1) buffers until a whole line has been read. One write instead of n. Is the dynamic buffer size bad and overkill? Maybe. Ask the author why a static buffer and multiple writes weren't used. Again, most lines are shorter than 8k, the buffer size cat(1) uses, and most lines will fill up quickly.
If your input is line unbuffered or line buffered already, you don't gain anything. If the process that writes to read(1) buffers its output for more than a line, this is also very little help. But can you now tell what the difference between these two lines are?
cat my-file | my-interactive-program
read my-file | my-interactive-program
And you seemed convinced that the operating system did this or that based on your interpretation of the manual of a user land program. Don't be so quick to jump to conclusions just because Uriel claiming
cat -v wad bad made you sad. Look at the sources directly and you can see what write(1) does and doesn't do.