> > Almost exactly right, except replace "unbuffered" with "line-buffered
> > output". Bash uses stdio and sets stdout and stderr to line-buffered.
> > The advantage of fully-buffered mode shows itself when writing large
> > amounts of data, which the shell does not do very often. The
> > advantage of line-buffered mode is better response.
>
> 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?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
