On 06/10/2017 14:35, Paul Moore wrote:
On 6 October 2017 at 13:56, bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list
