The "loop and a half"

[bartc]

On 05/10/2017 18:01, Chris Angelico wrote:
> On Thu, Oct 5, 2017 at 10:26 PM, bartc <bc at freeuk.com> wrote:
>> 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.
> 
> How would you write a sort program? How would you tell it that you're
> done entering data?

How do you do it with any kind of iterative program?

It can be done with an in-band end-of-data code, although it might take 
some effort especially if you also want that to be invoked by pressing 
Ctrl-D. Then you can continue using a simple loop, and ignore dealing 
with 'EOF' on a keyboard.

> And yes, I have used sort(1) interactively, with no redirection whatsoever.

Yes, I tried typing 'sort' in Linux, where it apparently hangs (same on 
Windows actually). The reason: because it might have killed someone to 
have added a message saying what you are expected to type and how to end 
it. (Namely, press Ctrl-D start at the start of a line in Linux, and 
Ctrl-Z followed by Enter, I think also at the start, in Windows.)


-- 
bartc