Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)

[Guy Harris]

>>Perhaps we should begin to make a really SERIOUS distinction between
>>direct human input and other kinds.
>
>*DON'T EVEN THINK ABOUT THIS!*  The ability to arbitrarily redirect
>input and output among devices/files/pipes/networks is what makes
>the unix toolbox approach work.  Take that away and you would have
>a fairly useless operating system.

Right.  So all OSes that don't let you do that are "fairly useless". 
Funny, lots of people seem to have uses for them....

There are plenty of UNIX utilities that are intended to be driven by a
human being - screen editors, for example.  While they might be *able*
to be driven from a file or pipe, I, at least, would be inclined to use
"ed" or "ex" in that context, not a screen editor (or the screen-editor
mode of some editor).

It's also not clear how the "don't distinguish" model applies to
window-system-style tools, where input doesn't necessarily consist of
the sort of stuff you'd stuff into a text file.

>Imagine wc working only with typed input - how often would you use it?

Lousy example.  "wc" takes all its *commands* (i.e., "count characters",
"count words", "count lines") from the command-line arguments; it
doesn't read *commands* from its standard input, it reads *data*.  "ed"
would be a better example - and, most of the time, I *don't* use "ed"
for editing, I use a screen editor, because it's less of a pain to use.

>I don't care to waste any CPU time watching for meaningless transitions
>of the <shift> key.

None of the systems I've worked with "waste" much CPU time "watching"
for "meaningless" transitions of the <shift> key; on Suns, for example,
and probably on a lot of other machines, the host is interrupted when a
key on the keyboard goes up or down, and, frankly, the keyboard driver
is not particularly near the top of the list of functions consuming CPU
time on a Sun.