The "loop and a half"

[Chris Angelico]

On Fri, Oct 6, 2017 at 11:38 PM, bartc <bc at freeuk.com> wrote:
> And is there any reason why you wouldn't use a text editor to capture your
> input first? I can see myself noticing an error I'd made 10 lines up, which
> is now too late to change, and I've still got 100 lines to go. What to do?

As has already been mentioned, this is frequently used with pasted
text. But if I'm typing it manually, it's because there aren't a
hundred lines to go, there might be a dozen. What to do? Hit Ctrl-D,
let it spam its output, and then start over, probably by highlighting
the previous text and using middle-button paste.

> I just can't anyone wanting to use programs that work in the way you
> suggest. Not outside of a student exercise (read N numbers and display the
> average), where getting the input correct isn't so important.

And since you've never personally worked this way, you scorn the concept.

Have you ever worked on a slow remote session where a GUI is
completely impracticable (or maybe even unavailable), and redrawing
the screen is too expensive to do all the time? You absolutely have to
work with line-by-line content. What text editor do you use there?

>> And since
>> every one of these programs is written to read from stdin until EOF,
>> you can use them all in exactly the same way - type at keyboard, hit
>> Ctrl-D when done.
>
> So they're all at it! That doesn't mean it's a good way of doing things.

Actually it does, because you learn the system once and use it for everything.

> On 06/10/2017 12:45, Chris Angelico wrote:
>> Why do you call redirection "crude"? Do you not understand the value
>> of generic solutions that work with all programs, rather than having
>> every program implement its own "take input from file" parameter?
>>
>> You can disagree with the Unix philosophy all you like, but when you
>> insult it, you just make yourself look like an idiot.
>
> Redirection is used on Windows too. I use output redirection quite
> frequently (to capture the output of 'dir' for example).
>
> I don't rely on > and < in my own programs. Where there's complex, mixed
> output, the bulk of it - the data - needs to go to a proper file, while the
> screen shows messages.

That's why we have the stderr stream as well as stdout. You can
redirect stdout and still have messages go to the screen (via stderr);
or you can redirect stderr as well, sending those messages to a
logging facility. How do you do THAT with your program?

Also: can you use your program to write to a file on a different
computer? I can pipe a program's output into SSH. You can make a crude
intercom system like this:

ssh flurble arecord | aplay &
arecord | ssh flurble aplay

More practically, I've done remote backups by triggering something on
a remote system and then transferring it to the system I'm running the
script on. In one particular case, the CPU load of compressing the
data was impacting the (single-core) source computer, so I piped it
uncompressed to the recipient, deflating it on arrival:

ssh flurble dump_stuff | gzip >some.dump

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

I'm not sure what you mean by a working pipe system. Yes, the one
cmd.exe gives you is not nearly as flexible as what bash gives you,
but for the purposes of the examples given so far, I'm pretty sure the
Windows cmd.exe facilities are fine. I don't know about the actual OS
facilities, but unless you're trying to redirect input/output from/to
something other than a file or another process, that should be fine
too.

And as has already been said in this thread, it should not be a
problem to explicitly redirect that.

> BTW if I try:
>
>  > gcc <program.c
>
> it doesn't work (this on Linux). What happened to the generic solution?

"It doesn't work" is a terrible way to report this. What's the
problem? Is it possibly what's described fairly clearly in the error
message?

gcc: error: -E or -x required when input is from standard input

Oh look! "In the face of ambiguity, refuse the temptation to guess."
Since GCC is the GNU Compiler *Collection*, it won't assume that it
knows what language you want it to compile. When you give it a file
name with an extension, it will presume that that's correct (you can
override with "-x", but I don't remember *ever* needing to do that),
but otherwise, it doesn't guess, so you have to specify with "-x c" or
similar.

ChrisA