Hi Chet,
> > I see why it's line-buffered when writing to a terminal, but when
> > bash changes where stdout points it has the option to setvbuf(3) or
> > similar too based on what it knows about the destination, e.g.
> > /dev/pts/3 versus /tmp/foo versus /dev/udp/0x7f000001/4242. Does it
> > never do this then, and just leave things as line-buffered all the
> > time?
>
> Bash ensures that stdout and stderr are line-buffered, and leaves them
> that way. It's a guessing game otherwise. Say sockets and pipes both
> present themselves the same way. Do you fully buffer, which reduces
> pipe throughput and concurrency, unbuffer, which cuts performance
> dramatically, or assume that line buffering is the right choice the
> majority of the time?
Thanks for the reply. I understand it's behaviour now and agree sockets
and pipes could look the same. But a regular file ./foo on disk does
look different and it still seems odd that
printf '\n\n\n\n\n\n\n\n\n\n\n\n' >foo
does a dozen one-byte write(2)s. Still, at least it explains the UDP
behaviour.
Thanks again, Ralph.
