From: Caleb Clausen <vikkous@...>
Date: 2010-04-30T01:29:31+09:00
Subject: Re: Use of STDOUT.flush after puts

On 4/29/10, Alex DeCaria <alex.decaria@millersville.edu> wrote:
> Thanks everyone.  That is very helpful.  My remaining questions is "Why
> isn't Ruby's default state such that STDOUT.sync is always 'true'?  In
> other words, what's the advantage of having standard output buffered
> rather than instantaneous?  In every program I've written in Ruby I've
> always wanted anything written to standard output to appear
> instantaneously.

I had thought that stdout (and stderr?) were supposed to be line
buffered by default when attached to terminals, else fully buffered.
This is traditional unix stdio behavior, nothing to do with ruby per
se. Line buffered means that a flush is performed automatically by
stdio whenever a \n is printed (which would mean that puts always
flushes whatever it prints, since it always appends \n if one was not
present). Fully buffered is the same as $stdout.sync==false. 1.8 seems
to behave in the way I described, even tho the $stdout.sync flag is
false. 1.9 may well behave differently, since it bypasses stdio
buffering and does its own thing.

Here are the results of two experiments I did on the command line. In
the first, stdout is a real file, and clearly is unbuffered, since the
output is not printed to it right away. In the second, output is to
the terminal, and was printed right away (tho you can't see that here,
you'll have to take my word for it).

$ ruby -e 'puts "foo"; sleep 15; p $stdout.sync' > foop &  sleep 1; ls -l foop
[2] 6521
-rw-r--r-- 1 caleb caleb 0 2010-04-29 09:23 foop
$ cat foop
foo
false

$ ruby -e 'puts "foo"; sleep 15; p $stdout.sync'
foo
false