The "loop and a half"

[Chris Angelico]

On Fri, Oct 6, 2017 at 10:41 PM, bartc <bc at freeuk.com> wrote:
> On 06/10/2017 12:04, Rhodri James wrote:
>>
>> On 05/10/17 19:45, bartc wrote:
>>>
>>> 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.)
>>
>>
>> Actually it might.  Linux tools are written not to assume that stdin and
>> stdout are the console, because they frequently aren't.  Extra puff written
>> to stdout at best makes it harder to use in a pipeline, and at worst makes
>> it useless; tools that do that tend not to get used.
>
>
> A lot of people aren't getting it.
>
> 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.
>
> Except you simply wouldn't use an interactive version of any program that
> reads an arbitrary long list of uninterrupted data, no matter how the ending
> is indicated. You'd use a text editor, enter the lines at your leisure, go
> back and forth to check and edit as needed, THEN you would submit that file
> to 'sort'. As an actual input file.
>
> 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.

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. And since
every one of these programs is written to read from stdin until EOF,
you can use them all in exactly the same way - type at keyboard, hit
Ctrl-D when done.

> 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.
>
> Funnily enough, you now get a message, and a prompt. And when entering
> multiple lines of code, you get a prompt before each line. You can also
> terminate the sequence by entering a blank line.
>
> So it IS possible to do it properly after all!)

Actually, Python's interactive mode is completely different from its
file input mode. You're not really comparing like things here.
Python's incremental interpreter is *by nature* interactive, and
redirecting its input does not produce the same result as running
"python3 filename.py" would. Can you find yourself a better example?

ChrisA