The "loop and a half"

[bartc]

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.)

(In my IDE, if a particular C file is highlighted, then typing 'cpp' 
will invoke the currently selected C compiler's -E equivalent, then 
instantly show the result in the editor.

Looking at the script for that, that does make use of the -o option, for 
gcc, so I must have known about it.)

> 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.

I think they are different kinds of applications.

(As for the ability to chain these programs together, I have the same 
opinion of that as doing the same in program code when you use the 
result of one function/method call to feed in as the argument to the next.

They can both end up as long horizontal hard-to-follow (or to intercept) 
sequences.

I'd prefer to break them up using intermediate variables in the language 
and intermediate files in the shell.

And as you can see from my IDE's 'cpp' command, which works with 4 
different C compilers (a fifth doesn't properly support -E), there are 
other approaches developers can use.)

-- 
bartc