The "loop and a half"

[Peter J. Holzer]

On 2017-10-06 13:24, bartc <bc at freeuk.com> wrote:
> On 06/10/2017 14:11, Peter J. Holzer wrote:
>> On 2017-10-06 12:38, bartc <bc at freeuk.com> wrote:
>>> On 06/10/2017 12:51, Chris Angelico wrote:
>>>> What you REALLY mean is that you can't see the point of an interactive
>>>> sort command. It doesn't fit into your workflow. And that's fine. It's
>>>> not something you'd use very often. There are other programs, however,
>>>> that behave exactly the same whether used in batch mode or interactive
>>>> mode, and where you would do exactly the same thing as I described -
>>>> provide input, and hit Ctrl-D to mark that you're done.
>>>
>>> Examples?
>>>
>>> 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?
>>>
>>> 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.
>> 
>> I regularly use at least cat, wc and od this way (plus a few of my own
>> utilities like utf8dump). I'm sure I've used sort this way, too, though
>> rather rarely. I usually don't type the input but paste it in,
>
> Exactly. Probably no one ever uses these programs with actual live input 
> with the possibility of uncorrectable errors getting through.
>
> So not a good reason to use that coding pattern to write programs which 
> ARE designed for live, interactive input:

But you aren't arguing about programs which are designed for live,
interactive input, you are arguing about sort. Sort is designed as a
filter. It should be able to read from stdin (otherwise you couldn't use
it in a pipe) and the fact that this also works when stdin is a terminal
is just a bonus. The authors of sort would have to go out of their way
to prevent that and they didn't. I think that's a good thing: It's
occassionally useful that I can paste something directly into sort and
don't have to write it into a file first, and the rest of the time it
does no harm.

> print ("Enter blank expression to quit.")
>
> while 1:
>
>      buffer=input("Expr: ")
>      if buffer == "": break
>      try:
>          print (eval(buffer))
>      except:
>          print ("Error")
>
> print ("Done")

I hope you don't think this a good design for interactive input: It's
much too easy to hit enter once too often. Ctrl-D is much harder to hit
accidentally. In addition you could add a "user-friendly" command like
"exit" or "quit". Although I hate it when Ctrl-D doesn't work:
Ctrl-D - does nothing
exit - syntax error
quit - syntax error
bye - program exits.
There are way too many english words which a user might want to use to
indicate their intention to close a program. None of them is therefore
likely to work everywhere (and I'm not even talking about stuff like
"\q" or "~."). EOF is unambiguous (and Ctrl-D for signalling EOF is an
OS feature - the application knows nothing about it).

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp at hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel