re-directing 'rup' to a file

[Phong Vo[drew]]

In article <6580:Mar605:00:5591 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
: > you shouldn't need a whole pty just to get line buffering!
: 
: Agreed. This brings up a general question: How should the system have
: been organized in the first place to avoid such problems? People often
A simple rule that takes care of many of the common complains with buffering
is to turn on line buffering for any case that implies interaction
with a different active process, e.g., a pipe or a person with a tty.

: suggest an environment variable to control stdio buffering, but this
: doesn't seem like enough to me. I don't think stdio should even do the
: initial stat(), or provide isatty().
The above rule would eliminate the need for isatty().
The stat is still useful because it contains information that the library
can use to tune its buffering strategy. For example, if a file is opened
to read and it has only a few hundred bytes, the library should not allocate
a full page buffer. On systems with memory mapping, if a stream has the
appropriate attributes, the library may even try to memory map instead
of read/write with buffers.

:Do new users really expect ls or
: more to behave differently inside a pipe?
Users probably don't care one way or the other as long as things work.
The crux of the matter is really that the notion of
lines of text is ingrained in many common UNIX programs. They expect
to process a line at a time. Therefore, in any "interactive" situation,
they expect streams to be line-buffered. When this is not
the case, programs get stuck and users get annoyed.

:Does any program really
: benefit from buffering differently when it writes to a file? I doubt it.
: 
If you care about efficiency, then, sure, different schemes for buffering
can make a big difference.