Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!pacbell!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)
Message-ID: <7709@chinet.chi.il.us>
Date: 14 Feb 89 18:27:11 GMT
References: <25@torsqnt.UUCP> <225800127@uxe.cso.uiuc.edu> <7697@chinet.chi.il.us> <1016@auspex.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 33

In article <1016@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>>>Perhaps we should begin to make a really SERIOUS distinction between
>>>direct human input and other kinds.

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

Yes, to run monolithic applications.  Unix could do that too, I suppose..

>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.

How do you write programs to manipulate the stuff, then?  As a programmer,
I prefer to *eliminate* human input rather than optimizing it.  Obviously
I don't do freehand graphics.

>>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;

But it illustrates the point I was trying (and apparently failed) to make.
I don't object to fancy interfaces, but they should be a "front-end" that
generates a standard interface for other tools. 

>None of the systems I've worked with "waste" much CPU time "watching"
>for "meaningless" transitions of the <shift> key; on Suns, for example,

Try executing sar on a '386 machine running VP/ix with a DOS process
active.  Note that the idle time is 0.  Perhaps keyboard scanning is
not entirely to blame - does the Sun 386i handle DOS better?

Les Mikesell