>>48,49
Blocking until you see a full line of input doesn't "break the fundamental pipe abstraction". It's actually a great example of how the abstraction works - read tokenizes input so the next process in the pipeline doesn't have to.
It's not that it blocks until it sees a full line, it's that it guarantees that it will output the full line with a single `write` call, presumably so that it will be returned by a single `read` call to the next program in the pipeline. Which means that those programs rely on a broken stream abstraction: suddenly fragmentation is no longer an implementation detail but an essential side-channel, the stream protocol is transformed into a datagram protocol, in a completely ad-hoc, unreliable way.
What's even more ridiculous, this can't
possibly work correctly on UNIX because there's no `read` function variant that allocates the buffer for you, as large as necessary. So the downstream programs that relies on its `read`s returning entire lines every time passes a fixed-size buffer, and guess what happens when the line is longer that that buffer: either the program just breaks, or it reallocates the buffer and tokenizes input again -- in other words, duplicates the work that `read` program did, making it unnecessary.
Obviously most real programs will do the former, because lines longer than 8k don't real. This bullshit is one of the most perfect examples of the smelly unix hacker culture I've ever seen.