The "loop and a half"

[bartc]

On 06/10/2017 14:35, Paul Moore wrote:
> On 6 October 2017 at 13:56, bartc <bc at freeuk.com> wrote:
>> If you don't like the word 'crude', try 'lazy'. Take this example of the gcc
>> C compiler:
>>
>>   > gcc -E program.c
>>
>> This preprocesses the code and shows the result. Typical programs will have
>> many thousands of lines of output, but it just dumps it to the console. You
>> /have/ to use '>' to use it practically (Windows doesn't really have a
>> working '|' system.)
> 
> No you don't. Ignoring the fact that "windows doesn't really have a
> working '|' system" (which is an oversimplification, by the way) the
> following all work:
> 
> Python:
>      data = subprocess.check_output(["gcc", "-E", "program.c"])
> Powershell:
>      $x = (gcc -E program.c)
> cmd:
>      for /f %i in ('gcc -E program.c') do ...
> 
> If gcc -E wrote its output to a file, you'd have to read that file,
> manage the process of deleting it after use (and handle possible
> deletion of it if an error occurred), etc.

But if I use the -S option (show assembly listing) that DOES output to a 
file (program.s).

If I use -fdump-tree-all, that also goes to a file (various).

> 
> Writing to stdout is very often a good design. Not always, but nothing
> is ever 100% black and white, but sufficiently often that building an
> OS based on the idea (Unix) was pretty successful :-)

The first computer I used was via a teletype printing on paper. If every 
operation producing an arbitrarily open-ended amount of output defaulted 
to the terminal, then it would have been totally impractical (in time 
taken and the amount of paper used).

Even with today's consoles, 80,000 lines whizzing up the screen (when 
program.c contains '#include <window.h>'), while not taking quite that 
long, still seems crazy to have as the default operating mode.

But you will say, Ah but you will never see it because it will nearly 
always be piped into another program.

And that reinforces the point I keep making: many of these are internal 
utilities never intended to be used as properly interactive commands.

Fine, but why keep bringing them up as models of how to write true 
interactive programs?


-- 
bartc