Date: Sat, 2 Dec 2000 15:08:11 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Sue Blake <sue@welearn.com.au>, freebsd-questions@FreeBSD.ORG Subject: Re: "unbuffered" ? Message-ID: <p04330106b64f0472caa4@[128.113.24.47]> In-Reply-To: <20001202224250.L377@welearn.com.au> References: <20001202224250.L377@welearn.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:42 PM +1100 12/2/00, Sue Blake wrote:
>I've seen this sort of thing in several man pages:
>
>cat(1)
> -u The -u option guarantees that the output is unbuffered.
>tr(1)
> -u The -u option guarantees that any output is unbuffered.
>tee(1)
>... The output is unbuffered.
>
>What does unbuffered mean, and how is it useful to know or
>manipulate that?
Usually output is buffered (in memory) for performance reasons.
When writing into a file, for instance, it often does not make
any difference if the OS were to wait a little while, and then
write out several lines at once, instead of writing every byte
the instant the program asks it to.
For interactive situations, this is obviously not workable. A
program writes a prompt to the terminal, and then waits for an
reply. This could be a long wait if the user hasn't seen the
reply! Even if the program is just writing regular output (ie,
and not waiting for a reply), it might be the user will want to
do something the moment they see a certain message pop up. For
this reason, I/O to a terminal is not buffered by default.
But that's if the output is going directly to a terminal.
Consider:
./myprog | more
The "myprog" process has no way of knowing that the output is
really going to some terminal, so that process will feel free
to buffer output for performance reasons. This usually is
the right thing to do when output is going thru a pipe to
another process, but in the above case this decision might
not be good.
So, some programs include an option so the user can specifically
request that the output should not be buffered.
You will sometimes notice the result of buffering when doing a
./myprog | more
where "myprog" is writing one set of messages to stderr, and
another set to stdout. Those lines will be displayed in a
different order relative to each other, because the lines to
stdout are being buffered up before 'more' will print them.
In those cases, you may find it useful to do:
./myprog 2>&1 | more
so that both the stderr and stdout messages are going thru
the 'more' process.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p04330106b64f0472caa4>