Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Dec 2000 17:01:38 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Ryan Younce <ryan@manunkind.org>
Cc:        Sue Blake <sue@welearn.com.au>, freebsd-questions@FreeBSD.ORG
Subject:   Re: "unbuffered" ?
Message-ID:  <p04330103b64f1ff04070@[128.113.24.47]>
In-Reply-To: <20001202152647.A40048@cheshire.manunkind.org>
References:  <20001202224250.L377@welearn.com.au> <p04330106b64f0472caa4@[128.113.24.47]> <20001202152647.A40048@cheshire.manunkind.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 3:26 PM -0500 12/2/00, Ryan Younce wrote:
>Thus spake Garance A Drosihn <drosih@rpi.edu>:
>>  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.
>
>Actualy, for what it's worth in this thread, myprog can determine
>whether or not output is going to a termianl by calling isatty()
>on STDOUT_FILENO.  This is how ls(1), for instance, determines
>whether to use single-column or multi-column output (ls will print
>multi-column if output is to a terminal and single-column if it
>is to a file, but command-line options can change this behavior,
>of course).

I tried 'ls'
vs      'ls | more'

and ls still treated the second case as "not a tty".  This is
understandable, as stdout to 'ls' is not a tty, it is the stdin
for 'more'.

I am not sure if that has any bearing on what you meant to say,
but given the context some people might think that you meant
that './myprog' could possibly fix the buffering problem by
calling isatty().  It can not.  That 'more' could just as
easily be a 'grep', which means some lines might go to stdout,
and other lines would not.  Once lines enter a pipe, there is
no way for the initial process to know whether those lines are
"really going to wind up" on the terminal.

-- 
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?p04330103b64f1ff04070>