The "loop and a half"

[bartc]

On 06/10/2017 18:55, Marko Rauhamaa wrote:
> bartc <bc at freeuk.com>:
> 
>> The internal utilities used within an operating system, primarily
>> intended for file or redirected i/o with no live interaction, should be
>> distinct from those designed to be used directly with a live user.
>>
>> Or is it against the rules of Unix to have two different versions of a
>> program?
>>
>> Then you might have 'sort' for the non-interactive version, and 'isort'
>> or whatever for the interactive.
> 
> You are right that interactive programs exist and operate very
> differently from what are known as *tools*.
> 
> Interactive Linux programs include:
> 
>      LibreOffice
>      NetworkManager
>      Firefox
>      Skype
>      XBoard
>      Emacs
>      GIMP
>      top
>      gdb
> 
> etc.

I meant interactive programs that work with a scrolling display, as 
suits a program like this:

  while 1:
     print (input("?"))

Considerations of the 'eof' status of a keyboard would of course be 
irrelevant for anything more sophisticated, either with a more organised 
console app, or one using a GUI.

> I don't know if anybody has seen a market/need for an interactive sort
> program, but there's nothing preventing you from writing one.

For sort, there is no real need. You use a text editor to create your 
data. Then use existing file-based sort.

>> So I can't see the point of using that same pattern of input usage
>> (reading from stream, file, pipe whatever until interrupted with an
>> EOF signal) for a true interactive program that is used in a sensible
>> manner.
> 
> So go ahead and write an interactive sort program. It might employ a
> mouse, joystick, iris scanner, touchscreen, sound effects or whatever
> facilities you would think would be useful for the human user.

It wasn't me who brought up 'sort' when the subject was interactive 
keyboard dialogues (it was Chris I think).

>> A program like 'python' might fit the bill too. Here, you can give it
>> the name of a file, OR say nothing, and it will take input from stdin.
> 
> Personally, I think stdin is a bit lame as a stimulus source for an
> interactive program. That's not even what stdin is primarily meant for;
> stdin is meant to be the input data for a job. Similarly, stdout is
> meant to be the result of the computation. Stderr, then, is used to
> deliver optional diagnostic messages, ie, metainfo about the
> computation.

You really need punched tape or cards for input and output to get the 
full effect. Complete with all the sound effects. Sadly when I came into 
it, we were using mag-tape for input (with a variety of outputs).

The clatter of an ASR33 printing your results was also a treat.

-- 
bartc