[comp.sys.amiga] QMouse vs. ARP1.3 query

rb@pur-phy (Ross Bogue) (05/18/89)

Not having a copy of Rob Peck's "runback" kludge, I've been starting
Qmouse from my startup-sequence by

	mount NULL:
	run >NULL: QMouse -Fs:qmouse.config

This works just fine on my regular boot disk (a 1.3 GVP+Q40).  The startup
CLI exits normally, presenting me with the Workbench screen.

If I try the same thing from an ARP1.3 floppy, the startup CLI doesn't exit.

Why not?  Any ideas?  Am I missing something obvious?  I've tried several
command-line permutations.  Using Arun doesn't help.  Using NIL: doesn't
work at all.


Ross Bogue
rb@physics.purdue.edu

(My wish for 1.4?  Punt NIL.  Replace it with a true NULL.)

rap@rap.ardent.com (Rob Peck) (05/19/89)

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