Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!olivea!tardis!tymix!uunet!mcsun!cernvax!chx400!urz.unibas.ch!balmer
From: balmer@urz.unibas.ch
Newsgroups: comp.os.os9
Subject: Re: Can't execute "J" - Error #000: 216
Message-ID: <1991Jun20.135408.1658@urz.unibas.ch>
Date: 20 Jun 91 12:54:08 GMT
Article-I.D.: urz.1991Jun20.135408.1658
References: <1991Jun18.033225.12476@mmm.serc.3m.com> <1991Jun18.184533.1648@urz.unibas.ch> <1991Jun18.235439.6486@ncsu.edu> <1991Jun19.063541.16459@wlbr.imsd.contel.com>
Organization: University of Basel, Switzerland
Lines: 28

In article <1991Jun19.063541.16459@wlbr.imsd.contel.com>, pete@wlbr.imsd.contel.com (Pete Lyall) writes:
> Kevin Darling suggest having the 'J' command eat up all of the
> standard input... a good suggestion (Kev - where have I seen that
> before.. grin)...
> 
> Another alternative... If the OSK shell works like the OS9/6809 shell,
> when a procedure file is run, a child shell is forked from the
> original shell with its standard input redirected from the alleged
> script/procedure file. The 'J' command could simply get a copy of its
> process descriptor (F$gprdsc, or whatever), determine its parent's
> process ID (the secondary shell's ID), and it could send a KILL
> signal, terminating the erroneously spawned 'procedure' shell.
> 
> Pete
> 
> -- 
> Pete Lyall [GTE]   Compuserve: 76703,4230   Internet: pete@wlbr.imsd.contel.com
>                 UUCP: {hacgate,jplgodo,voder}!wlbr!pete 
> "... So I picked up my pride from beneath the pay phone, and combed his breath 
> right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friend

I suggest the following: The program J seeks to the beginning of its standard
input, then loads his standard input to a module (or saves it to temporary
file) and tries to execute the module or the temp. file.

I did not try it, but I'm sure we could get this running.

- Marc