Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!ubvax!ardent!rap!rap
From: rap@rap.ardent.com (Rob Peck)
Newsgroups: comp.sys.amiga
Subject: Re: QMouse vs. ARP1.3 query
Message-ID: <6541@ardent.UUCP>
Date: 18 May 89 17:19:06 GMT
References: <2270@pur-phy>
Sender: news@ardent.UUCP
Reply-To: rap@rap.ardent.com (Rob Peck)
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 74

In article <2270@pur-phy> rb@pur-phy (Ross Bogue) writes:
>Not having a copy of Rob Peck's "runback" kludge, I've been starting
>Qmouse from my startup-sequence by

(STRICTLY FROM MEMORY... but provided just so folks can
 get the general idea).

/* RUNBACK.C */
#include <exec/types.h>
#include <dos/dos.h>
#include <dos/dosextens.h>

extern struct FileHandle *Open();
extern int Execute();
char *first = "RUN >NIL: <NIL: "
char *second = " >NIL: <NIL: "

/* note the embedded blanks */

main(argc, argv)
int argc;
char **argv;
{
	struct FileHandle *nilfh;
	int success, length, i;
	char c[255];

	nilfh = Open("NIL:", MODE_NEWFILE);  /* correct I think */

	length = strlen(first);
	strcat(c, first);  /* build first part of exec string */

	strcat(&c[length], argv[1]); /* add the command to it */
	length = strlen(c);

	strcat(&c[length], second); /* add redirection to command */
	length = strlen(c);

	for(i = 2; i<=argc ; i++)   /* and finally add the parameters */
	{
	    strcat(&c[length], argv[i]);
	    length = strlen(c);
	}	
	success = Execute( c, nilfh, nilfh );

	/* Deliberately don't close NIL: ... we have no idea how
	 * long the command is gonna hang around after we leave.
	 * So we got a lock hanging around (only uses 8 bytes,right?)
	 */
}

The user enters:

	RUNBACK COMMAND PARM1 PARM2 ... PARMN

The resultant full parameter set fed to Execute() looks like:

   ("RUN >NIL: <NIL: COMMAND >NIL: <NIL: PARM1 PARM2 ... PARMN",nilfh,nilfh)

The "nilfh" partially detaches the command from the CLI, and
the redirection both on the run command as well as for the COMMAND
itself completes the job.  If you have "0" for either of the two
uses of "nilfh", it DEFINITELY locks up the originating CLI
because the handle to the originating CLI is passed to the child
process whether it needs it or not.	

NOTE: The LATEST version on Fish disks follows a similar route,
but is smart enough to use the PATH to find the COMMAND.
Suggest you try to find the latest version, for an assured
accurate source code, as well as the use of PATH.  This newest
variation was based on my original source (similar if not identical
to the above).

Rob Peck