The "loop and a half"

[bartc]

On 05/10/2017 12:09, Chris Angelico wrote:
> On Thu, Oct 5, 2017 at 9:56 PM, bartc <bc at freeuk.com> wrote:
>> This doesn't make sense. For interactive use, you wouldn't bother testing
>> for eof, as you'd be testing the eof status of the keyboard.
> 
> You mean the way heaps and heaps of Unix programs work, processing
> until EOF of stdin? Yeah, totally makes no sense, man, no sense at
> all.

Out of the hundreds, perhaps thousands of such input loops I must have 
written, how many needed to test EOF? Hmm, somewhere around zero I think.

Oh hang on, I wasn't using Unix; does that make a difference?

If you're referring to the ability to redirect stdin so that input can 
come from a file as well as from a live keyboard, then you're doing file 
handling; it's NOT interactive.

(And I've used such programs where you get no prompt as to what to type, 
or how to finish, and you just blindly press Ctrl C, Ctrl D, Ctrl Z or 
Ctrl Break in turn until it stops. Really friendly. Because the program 
reads from stdin but assumes it comes a from a file or pipe anyway.)

Note that Unix way isn't the ONLY way of doing things.

-- 
bartc