On 2017-10-06 11:41, bartc <b...@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.
How would that stop your clueless user from invoking sort and thinking
that it hangs? Short of putting it into /usr/lib or so, but that would
make it hard to use in a pipe.
I can see some merit in the idea that filters could print a short help
message when reading from a terminal, but creating a second
"interactive" version of each filter with a different name seems to be
utterly pointless to me.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
--
https://mail.python.org/mailman/listinfo/python-list
