[Toybox] Sigh. What needed setlinebuf(break_everything) again?

[Rob Landley]

On 11/21/20 10:01 AM, Rob Landley wrote:
> On 11/21/20 9:52 AM, Rob Landley wrote:
>> Because it broke watch. (When you fill the screen it never displays the last
>> line of output until you hit "q".) And it broke tee, and it broke...
>>
>> Why did it go in again? What was the problem being solved? I've noticed that I'm
>> using a lot more dprintf(1, "blah") these days just to prevent having to deal
>> with the fact that xprintf() got broken and no longer actually produces output
>> until random future things happen...
> 
> It's because adding a --line-buffered option seemed crazy:
> 
> http://lists.landley.net/pipermail/toybox-landley.net/2019-April/010342.html
> 
> And because xprintf() got nerfed to be useless (not actually flush). Watch is
> actually calling xprintf(), it just doesn't _matter_.
> 
> Great: stdout needs nagle's algorithm.
> 
> Does anything OTHER than sed and grep care about this particular performance
> weirdness?

Trying to figure out what the standard says, and according to
https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html stdout is
buffered when it DOESN'T point to a terminal, but
https://linux.die.net/man/3/stderr says it's line buffered when it DOES point to
a terminal.

Here are people arguing about how Rust should behave:

https://github.com/rust-lang/rust/issues/64413

Rob