On 05/10/2017 18:01, Chris Angelico wrote:
On Thu, Oct 5, 2017 at 10:26 PM, bartc <b...@freeuk.com> wrote:
On 05/10/2017 12:09, Chris Angelico wrote:

On Thu, Oct 5, 2017 at 9:56 PM, bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to