Path: utzoo!attcan!uunet!super!udel!gatech!ncar!ames!elroy!gryphon!keithd
From: keithd@gryphon.COM (Keith Doyle)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Amiga Roadblocks to User Friendliness
Keywords: ASSIGNS
Message-ID: <9946@gryphon.COM>
Date: 23 Dec 88 18:40:43 GMT
References: <9407@gryphon.COM> <1410010@hpcvca.HP.COM> <9910@gryphon.COM> <10866@swan.ulowell.edu>
Reply-To: keithd@gryphon.COM (Keith Doyle)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 61

In article <10866@swan.ulowell.edu> dfisk@hawk.ulowell.edu (David Fisk) writes:
>As a hard disk user, I've been following this discussion about ways to
>do software installations with Assign batch files. Personally I don't
>like having to have a lot of assigns that have to be made for all of
>my programs to work. What I would like to see is for programs to look
>for a configuration file in a certain directory (either current or a
>regular assign such as s:) and use that instead of Assigns. This is
>currently done by one shareware program I have seen, Access!, which makes
>things very neat and tidy. An installation program/script would copy
>the program files from the distribution media, to a user specified
>directory and then either run the program and have it prompt the user
>for configuration info, or create the config file itself. I think that
>this is a lot nicer than having someones script/program editing my
>startup-sequence.
>
>Any Comments?

Yes.  You can't use the current directory for anything because programs
run under the Execute() call don't know what their current directory is.
You MUST have a full pathname to such files.  Let's pose a scenario:

1. program A runs.
2. program A wants to cause program B to run.

Program A must be able to find program B, and if program A was run from
an Execute(), it can't reference it without a complete path name if A was
run from an icon.  Program A could concievably read file S:PROGA_CONFIG and 
find the supposed current path of program B, but it takes extra disk activity 
at run time over the assign approach.  Program A could read all of 
PROGA_CONFIG upon initial invocation so that the information is around all 
the time so that reading of this file is not done every time program B is 
invoked.

Now. Program B wants to use data files that are in the same directory
as program B.  Program B also has to read a config file to find out what
it's current directory is if it perhaps can't assume that an assign is
available.  We are using the config file as a workaround for the lack
of an assign, a facility which we DO have, so why not use it?

Program A wants to accept a filename typed in by the user.  Program A
must then parse the file name to determine if it is a complete or partial
path, if not complete, must prepend the config file's current directory
information as the operator is then presumed to be specifying the file
as relative to program A's directory.  But what if program was run via
PATH ADD from another directory, and the current directory there is
not the same as is in the config file?  This one's a mess.  If the user
knew that program A's directory was FOO:, assigned at startup, he could
specify FOO:filename when he knows he want's it in program A's directory
and "filename" by itself when he is in the directory he wants and the program
has not been Execute()'d from another icon-invoked program.

Ultimately, the best way to fix all these problems is to fix Execute() to
correctly inherit the path of the parent process even when the parent was 
invoked from an icon.  In that instance, 99 percent of the reasons one
needs startup assigns go away.  Startup PATH ADDs may still be necessary
however, and there's no amount of config-file reading an application will
be able to do to cure it if the PATH ADD is required to get to the application
in the first place.

Keith Doyle
keithd@gryphon.COM    gryphon!keithd     gryphon!keithd@elroy.jpl.nasa.gov