The "loop and a half"
bartc
bc at freeuk.com
Fri Oct 6 15:18:33 EDT 2017
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
More information about the Python-list
mailing list