Re: Built-in printf Sits Awkwardly with UDP.
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/0x7f01/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.
Re: Built-in printf Sits Awkwardly with UDP.
> > 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/0x7f01/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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Built-in printf Sits Awkwardly with UDP.
Ralph Corderoy wrote: > ... 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. But the only reason you know that there is a long string of newlines is that your eye is looking over the entire string. It has all of the data all at once. You have a non-causal relationship with the data because you are looking over all of the past history of the data. By the time we see it here it has all already happened. You are not looking at the data as it arrives. In other words... Are you trying to suggest that a program should try to look-ahead at future characters? Characters that may not yet be written yet? That would be a cool trick of time travel to be able to know what is going to happen in the future. When you as the program see a newline character do you know if the next character that has no yet been generated yet will be a newline? Should it wait a timeout until characters have stopped appearing? It really isn't a problem that can always be solved perfectly in every case. Bob
