🚀 go-pugleaf

In article <11752@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) writes:
>On the other hand, if for some
>  reason you wanted to invoke one module process from inside another, this
>  is pretty easy: simplest is to use the AmigaDOS call
>
>         Execute("run module")
>
>  (You would have to use "run" so you would come back to your invoking
>  module immediately.)  You might LoadSeg() and CreateProc() instead, but I
>  don't see much advantage in that.

Both Execute and LoadSeg()/CreateProc() have big problems
because they lead to lots of situations that confuse the hell out
of novice users.  You have to do a Execute("run name:module",0,0); because
Execute("run module",0,0); is equivalent to Execute("run df0:module",0,0); 
or maybe sys:module or something that bears no resemblance to what you are
really trying to do.  If you *do* do an Execute("run name:module",0,0); 
then either the novice can't boot off of *his* vanilla workbench disk 
because the assign name: doesn't get done, or you have to name the disk 
"name" and if you do that, the novice who forgets after backing up to edit 
the "copy of " out of the name, thinks the disk is copy protected because 
it keeps popping up requesters saying "please insert volume 'name' in 
any drive".  You'd be surprised how many novices I've talked to who did 
edit "copy of" out of the name, but didn't catch the space between "of" 
and "name".  It looks like it's the correct name, but AmigaDos doesn't 
treat them the same.
 
If you use LoadSeg, you can specify a file without full path name, relative
to the current directory which should be the one the original icon was
clicked on.  As long as all paths are relative to that directory, no
assigning or disk-name assumptions have to be made.

The problem with LoadSeg though, is if "module" itself want's to open files
relative to the directory it is in, unless you can feed to the new
CreateProc()'ed process your current directory, it won't work.  I haven't
yet checked to see if you can feed a created process it's current directory.

I'm thinking the only real way to make this all work with a minimum of
pain to the novice user, is for the original program to use successive
ParentDir()'s to construct its full path name, build and Execute() an
'Assign here: currentdirpath' command and then have everyone use here: to
find associated programs and files.  Kludgy, but it works.

What I'd like to be able to do (if it worked) is this:

	1. boot a vanilla workbench, no custom Assigns in startup-sequence
	   required.
	2. put application disk in df1: or df2: or ??(and disk can be 
	   named anything)
	3. click on drawer icon on application disk to open drawer named 
	   "appl" which contains subdirectory "stuff".
	4. click on application icon in drawer "appl"
	5. application does an Execute("run stuff/subpart",0,0);
					 ^^^^^^ note relative to application's
						current dir, "appl"
	6. "subpart" program does an Open("datafile",...).  Where datafile
	   is a relative reference (either to "appl" or "stuff", I could work
	   within either constraint).
	7. All of this stuff will still work flawlessly if you copy the entire
	   application disk into a subdirectory on a hard disk.

Unfortunately, this won't work as step 5 fails with a nonexistant 
command error reported on the CLI.  This would work if run could find
the command in the Executing program's current directory.  Makes me wonder
if a substitute RUN command could be created that would fix the problem.

And you can't do an Execute("run :appl/stuff/subpart",0,0);, as that will
violate condition 7.

If I use the technique I described above constructing an Assign here:
command, and the references in 1-7 above become here:stuff/subpart etc.
it will work, and only makes the assumption that the Assign command is
available.  Kinda hate hardcoding Assign commands in programs,
but nothing else seems to work, unless I can feed CreateProc it's
current directory somehow.  I still end up having to ParentDir it up
the tree to find out what the complete current directory path is.

If anyone can think of another method of meeting the 1-7 criteria
above, I'd be glad to hear it.

BTW, this also touches on a reason I have a big problem using anybodies
*.library for anything useful, as novices don't have the foggiest notion on 
how to install them.  An auto-install program has the problem that the 
vanilla workbench is too full, requiring something to be deleted.

Keith Doyle
#  {ucbvax,decvax}!trwrb!cadovax!keithd  Contel Business Systems 213-323-8170