stdio line-streaming revisited

[Georg Wrede]

Kris wrote:

> Bingo! It blows me away just how much attention the lowly console is 
> recieving :)

It should.

Before C++ introduced cin and cout, most console I/O was [by the average 
programmer] written with routines specifically reading from the keyboard 
and writing to the screen, in DOS and Windows. Even for "line oriented 
programs".

In Unix, the I/O has always been a more general concept (we all know, 
but I'm writing this for others to read too), and I/O redirecting is 
more the rule than the exception with non-GUI apps.

Therefore, text-in-text-out programs should always use the standard 
handles. Only when very specific circumstances exist, one may do "direct 
'console I/O' or the like". As a matter of fact, I don't remember any 
such apps or situations off-hand, although they certainly may exist.

We need this compatibility with "the Unix way" for two reasons: most 
programmers have to write D for both platforms (and actually "the Unix 
way" should be called "the non-Windows way").

The second (and admittedly more controversial) being, IMHO Vista is the 
last Windows version to come out of Redmond. The next will be based on 
*nix, one way or another. Just like Apple did. (Please everybody, 
counterarguments to this should be in some new thread, not in this one.)


This is not merely a convenience in Unix, it is _the_ fundamental 
concept of the operating system. Everything is text files, and every 
[non-GUI] program's I/O is redirectable.

Adherence to this has brought us with vastly simpler debugging, 
protocols, and utility of existing programs in ways not envisioned by 
the original programmer. And this is the precise reason why one can, 
using only Telnet (a trivial terminal emulator), directly interact with 
a mail server, or get web pages, even when one's computer does no graphics.


As an example, my first stab at the plastics processing software was a 
quick-and-dirty version that showed the temperatures and settings on the 
console. I did some cursor addressing and coloring of the output, but as 
I was on Linux, it all was to stdout.

The output was only almost what I wanted, so I ran the program simply 
redirecting its output to a file

   myprog > myfile

Looking at the file I could see the individual terminal escapes and 
immediately found my cursor addressing bug.

Later I wanted to see a lot of live data for temperature algorithm 
debugging and signal to noise ratio data. So I created some text output 
which I sent to stderr. Then I invoked the program like

   myprog 2>/dev/tty7

and I could follow the debug output in real time, without messing up the 
normal display.

Later it turned out I wanted historical data, so I invoked the program as

   myprog 2> mylog

and when it turned out that the new machine operator was computer 
illiterate, I wrote a startup script

   #!/bin/bash
   myprog 2>> mylog

...I could go on and on, but the idea is clear here: if I had originally 
written the program to read the keyboard directly and write to the 
screen buffer, I would have had a lot of work to do to accomplish this all.

Incidentally, now I have both logging and a real time display just by at 
any time opening a second session and writing

   tail -f mylog

----

To recap, the proper default way to do I/O is to use the pre-existing 
filehandles for all non-binary data. Tango should have the routines and 
documentation such that it steer the programmer to do just that.