On 06/10/2017 18:55, Marko Rauhamaa wrote:
bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list
