Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!ucbvax!jade!ucbopal!mwm From: mwm@ucbopal.berkeley.edu (Mike (I'll be mellow when I'm dead) Meyer) Newsgroups: net.micro.amiga Subject: spawn.c for use under workbench Message-ID: <702@jade.BERKELEY.EDU> Date: Thu, 15-May-86 04:34:26 EDT Article-I.D.: jade.702 Posted: Thu May 15 04:34:26 1986 Date-Received: Mon, 19-May-86 00:53:20 EDT Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) Organization: Missionaria Phonibalonica Lines: 49 I sometimes run microEmacs from the workbench, where it has the obnoxious habit of locking up the system when you endcli after a spawn-cli. Amiga hack has the same bad habit. The spawn-cli below fixes this problem, though it is somewhat ugly. As far as I know, this doesn't do anything that will break the system; I'm sure I'll find out soon enough if someone else finds such a creature :-). Those of you who don't run microEmacs from the workbench should probably ignore this. Those working on porting the latest Hack to the Amiga should probably pick it up. #include #undef TRUE #undef FALSE #include "def.h" /* AFTER system files to avoid redef's */ /* * Create a subjob with a copy * of the command intrepreter in it. Since the command * interpreter doesn't run in the same window, there's no * need for a refresh. Ah, the beauties of windowing system... */ spawncli(f, n, k) { struct FileHandle *nilfh, *Open(); eprintf("[Starting new CLI]"); nilfh = Open("NIL:", MODE_NEWFILE) ; if (nilfh == (struct FileHandle *) 0) { eprintf("Can't create new CLI window"); return (FALSE); } Execute("newcli \"CON:0/0/640/200/MicroEmacs Subprocess\"", nilfh, nilfh); Close(nilfh); return (TRUE); }