USER question

[Bill Campbell]

On Tue, Dec 16, 2008, Fairlight wrote:
>At Tue, Dec 16, 2008 at 04:24:44PM -0500 or thereabouts, 
>suspect Kenneth Brody was observed uttering:
>> Quoting Fairlight (Tue, 16 Dec 2008 15:59:41 -0500):
>> 
>> > Is it possible to generate EOF on the outgoing stream to a program without
>> > closing the entire USER session?  Likewise, how do you detect EOF on the
>> > incoming stream from USER if the external isn't purposely built for use
>> > with fP?
>> 
>> The only way to generate EOF on a pipe is to close the pipe.
>
>Which...I of course knew. :) Guess I'm more tired than I thought,
>re-reading the question and how I phrased it.  Not to mention being ill.
>Bleh.
>
>I just figured maybe you had a mechanic hidden away in there that wasn't
>exactly advertised and didn't rely on the pipe.  Could have been more to it
>than that.
>
>Okay, so USER is pretty much useless in a scenario where you need to give
>something STDIN from fP's STDOUT, and get the STDOUT from the process back.
>There's no way to EOF it and read back all in one session.  I can think of
>a few (ugly, ugly, UGLY) ways to work around this, but...  Yeah, the
>suggestion of USER from earlier in the week is a non-starter.

I had a system that required some 80286 Xenix binaries tied into FilePro,
with some fairly neat menus that had hard-coded Radio Shack DT-100 terminal
codes, programming function keys on the fly.  Of course the source code for
this program was long gone.

I wrote a shim program that spawned two processes, similar to what
communication programs like ckermit do, sitting between the x286 binary
program and the terminal.  The processes communicated with shared memory
with the process listening to Filepro intercepting the codes to reprogram
function keys, updating the shared memory key map.  The process talking to
the terminal and keyboard looked for function keys sent, mapping them to
the appropriate DT-100 codes.  The only difficulty was that it tended to
use up shared memory when people didn't log off properly so required
manually clearing it.

Bill
-- 
INTERNET:   bill at celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186

To say that UNIX is doomed is pretty rabid, OS/2 will certainly play a role,
but you don't build a hundred million instructions per second multiprocessor
micro and then try to run it on OS/2.  I mean, get serious.
    -- William Zachmann, International Data Corp