The "loop and a half"

[Ben Bacarisse]

bartc <bc at freeuk.com> writes:

> On 07/10/2017 01:14, Ben Bacarisse wrote:
>> bartc <bc at freeuk.com> writes:
>>
>>> 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.)
>>
>> 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.