bartc <b...@freeuk.com> writes: > On 07/10/2017 01:14, Ben Bacarisse wrote: >> bartc <b...@freeuk.com> writes: >> >>> 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.) >> >> Does the Windows version of gcc not support the -o file option? > > I never thought of trying it. But OK, you have to use -o or > to stop > the output from swamping the console. (| might work if I could find a > program that captured the piped output for the purpose of browsing.) <snip>
>> And a good system lets you alter that. How many labels are generated >> for some code? Let's see: >> >> gcc -S -o /dev/stdout t.c | grep -c '^\.L' >> >> Now gcc also permits -o - (it's a common Unix convention) but you can >> almost always get round less helpful programs using /dev/sdout. > > I'm not really arguing against this. I'm disputing the suggestion that > because these utilities, which are rarely given data actually typed > from the keyboard, work by reading from stdin using an eof-checking > loop, that the same method must always be used in programs that really > are reading data from the keyboard. And I'm not arguing about that -- I know there is no point. The way Usenet works is that I reply to the parts I want to comment on. No one can see what made me make the above remark because you cut it, but the combined effect of the two remarks of yours that I commented on was to suggest that gcc makes arbitrary choices about output destinations (and I assume gcc was just an example). I was simply saying that a good OS can finesse such matters. <snip> -- Ben. -- https://mail.python.org/mailman/listinfo/python-list