home *** CD-ROM | disk | FTP | other *** search
- RunBack version 6. Original program by Rob Peck.
- *
- * improved 8/10/89 by Doug Keller
- *
- * compiled with Lattice C v5.02 with:
- * -rr registerized parameters
- * -v no stack checking
- * -w short integers
- * -cusf unsigned chars, only one occurence of same
- * string, force prototyping
- * -O global optimizer
- *
- * linked wth cres.lib, program can be resident now!
- *
- *
-
- Runs programs in the background fully detached from the
- initial CLI, unlike the RUN command alone. CLI will not
- "hang around," waiting for the program to close.
-
- * Improved 7/14/89 by Greg Searle
-
- * Doesn't crash anymore when a task tries to access the CLI.
- * Allows priority setting.
- * Major code cleanup and simplification.
-
- Usage: RUNBACK [[-]delay [priority]] command [arguments...]
-
- "delay" is a time in seconds for RunBack to wait for the command
- to load. This is useful if you are starting up many tasks from
- a script, and wish to avoid "disk-thrashing" caused by many
- tasks trying to load at once. Dash is optional (Kept for
- compatibility).
-
- "priority" is the system task priority that you wish to run this
- task at. Recommended values are -5 to 5, with the current
- priority being the default (usually 0). Theoretically may be
- -127 to 127, but this could lock out essential system tasks.
- Use this with care, as it's very easy to lock yourself out of
- the CLI or Workbench with a high-priority, runaway task.
-
- "command" is the program that you wish to run. RunBack
- simply passes on your arguments to the RUN command. This may be
- in your C: directory or in any other directory that your PATH
- is set to. This path will also be searched for your command.
- Order is totally up to AmigaDOS. It's a little strange.
-
- "arguments" are, of course, the arguments that you wish to pass
- to your program. Note that the program won't be able to input
- or output to the CLI, or to anywhere else. These are re-directed
- to the NIL: device.
-
- This version solves the major problem with the original: the system would
- crash when a program tried to input or output to the CLI. This is now
- corrected. The program will properly access the NIL: device, merrily
- outputting its data into the void, and receiving blank nothings for input -
- as it should be. I have yet to find a program that will crash with this.
-
- - Greg 7/14/89
-
- I took the liberty of removing obsolete code, files, and comments from this
- archive. Earlier README files are included after the dotted line. Version
- 3 was used as a base for version 5, so version 4's notes are not included
- here.
-
- Compiled in Manx 3.6a, but should compile in Lattice.
-
- -----------------------------------------------------------------
- Author: Daniel Barrett [version 3]
- Department of Computer Science
- The Johns Hopkins University
- Baltimore, MD 21218
-
- barrett@cs.jhu.edu
- ins_adjb@jhunix.UUCP
-
- Note: Both the original RunBackground and Which are in
- the Public Domain. So is all my code that I added.
- Use it however you please.
-
- INTRODUCTION
- ------------
- This is my altered version of Rob Peck's fine program, RunBack.
- RunBack, similar to Run, allows you to startup a CLI program and let
- it run in the background. Unlike Run, however, RunBack then allows
- the original CLI to be closed. Run would hang the CLI if you did this.
- See the file README.peck for Rob Peck's original documentation.
-
- Also unlike Run, the old RunBack did not search your command search
- path; you always had to specify the complete pathname of your command.
- My new version eliminates this hassle -- it searches your path.
-
- The path-searching code is largely taken from Carolyn Scheppner's
- "Which" program. Thanks, Carolyn!!
-
- A PROBLEM I HAD TO OVERCOME
- ---------------------------
-
- The original RunBack program I obtained was a binary version,
- compiled with the Lattice C compiler. I use the Manx (Aztec) compiler,
- version 3.6a. When I compiled Rob's original program with Manx, something
- did not work anymore... quoted arguments on the command line. The Manx
- version completely drops the quotes!
-
- The way RunBack works is that it translates:
-
- RunBack myProgram arg1 arg2
-
- into:
-
- Run >NIL: <NIL: myProgram >NIL: <NIL: arg1 arg2
-
- So a Lattice RunBack would translate from:
-
- RunBack c:emacs "my file"
-
- into:
-
- Run >NIL: <NIL: c:emacs >NIL: <NIL: "my file"
-
- HOWEVER, Manx-compiled RunBack translates it into:
-
- Run >NIL: <NIL: c:emacs >NIL: <NIL: my file
-
- which is clearly WRONG.
-
- What did I do about it? I added a few lines of #ifdef AZTEC_C
- code to the runback.c program, plus the file aztec.c. I am effectively
- replacing quotes around quoted arguments. My algorithm is this: if
- an argument has a blank space in it, then it must have been quoted, so
- put quotes around it.
- If you don't like this algorithm, the source code is included
- and you can change it any way you like.
- Since I don't have the Lattice compiler, I cannot be sure that
- my changes will work under Lattice. That is why I made all my changes
- #ifdef AZTEC_C, a constant that is automatically defined by Manx C
- after version 3.4a.
-
- Enjoy the program!
-
- -----------------------------------------------------------------------------
-
- --------------
- runbackground.c [original version by Rob Peck]
- ---------------
-
- SUMMARY: A Workbench Disk can be used to autostart an application
- through the use of the startup script and close the startup CLI.
-
-
- Users have commented that it is not possible to start a process going
- from the startup script and then cause the initial CLI to go away.
- Here is the solution to that problem, named appropriately:
-
- RUNBACKGROUND
-
- which starts and runs a background task. This does indeed allow you to
- create a startup script that will set up your workbench running any
- programs you might wish, removing the initial CLI in the process.
-
- Your s/startup-sequence can contain lines such as the following:
-
- RUNBACKGROUND -3 clock
- RUNBACKGROUND utilities/calculator
- RUNBACKGROUND -5 utilities/notepad
-
- where RUNBACKGROUND is the command and the second parameter is the filename
- which may be preceded by a flag-variable that specifies an optional delay
- time. The delay can be from 0 to 9, for the number of seconds that
- the startup script should sleep while allowing the background task to
- load and start. I've put that in to minimize thrashing of the disk as it
- tries to load several projects at once.
-
-
- LIMITATIONS:
-
- The program that you run cannot require any input from an interactive
- CLI that starts it. Additionally, you cannot specify any file
- redirection in the command line since this program provides the
- redirection for you already. If you need to use redirection for
- your command, you can modify the source code where shown, thus
- allowing the redirection to become one of the parameters passed
- through to your program.
-
- RUNBACKGROUND does pass your command line parameters to the program
- you wish to start, but limits the total length of your command
- string to 227 (255 minus the 28 characters for "RUN >NIL: <NIL: "
- preceding your own file pathname and ">NIL: < NIL: " following it.)
-
-
- LINKING INFORMATION:
-
- (Amiga/Lattice C) use -v option for pass 2 (lc2 -v filename.q)
- to disable stack checking code installation.
- (stack checking code sometimes is incorrect).
-
- FROM lib:Astartup.obj runbackground.o
- TO runbackground
- LIBRARY lib:amiga.lib, lib:lc.lib
-
- **************************** NOTE: ********************************
- If you use Lstartup.obj, it won't let the startup CLI go away. This is
- because the source code for Lstartup.asm either opens its own window
- or uses an existing CLI window (Open("*",....)), so that it has some
- guaranteed place to put the output. Astartup.obj does not do this.
- *********************************************************************
-
- Hope this helps.
-
-
- robp.
- */
-
-