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