Path: utzoo!attcan!uunet!mcsun!hp4nl!phigate!ehviea!leo
From: leo@ehviea.ine.philips.nl (Leo de Wit)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: The program's name and path - how can I get them?
Keywords: arcgsh
Message-ID: <897@ehviea.ine.philips.nl>
Date: 9 Oct 90 12:04:55 GMT
References: <1990Oct8.085411@heike.informatik.uni-dortmund.de> <1990Oct8.144907.12697@doe.utoronto.ca>
Reply-To: leo@ehviea.UUCP (Leo de Wit)
Organization: Philips I&E Eindhoven
Lines: 39

In article <1990Oct8.144907.12697@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes:
|In article <1990Oct8.085411@heike.informatik.uni-dortmund.de> klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes:
|>
|>However, what I need to know is the complete path of the executing program.
|>This is neccessary to read (resp. write) the configuration file which is in
|>the same directory as the program itself. 
|
|                                    There is _no_ legal way that I know
|of that you will always be able to do this. You can check to see if
|the program was started from a shell which supports the ARGV= protocol,
|but that's about it.

Well, there _is_ a legal way that I know of, but you may not like the
implications. Just write a TSR that traps Pexec calls and saves the
filename in a private buffer before letting GEMDOS take over. By some
communication with the TSR (various ways to do this) the newly started
program can find out its real name.

Some potential problems (and solutions) with this scheme:
a) In case of a relative pathname the TSR must prepend the current
directory in the private buffer. Piece of cake.
b) the application must check for the TSR to be present, and if it is
not, (perhaps install it and) exit with an error message to do a retry.
Not so big a problem, since the user will probably put the TSR in his
AUTO folder if he needs it frequently.
c) In case of a multiTOSking environment, there is a potential race
condition between the new program getting its full path and another
program being Pexec'ed at the same time (overwriting the static
buffer). If you want to solve this, you'll probably need multiple name
slots.
d) With Pexec(4,...) (go) you don't supply a name, so you can either
take the easy way out by aborting the program, saying you don't support
preloading, or keep the name supplied by Pexec(3,...) (load) together
with the basepage address - this might imply maintaining a list.
e) If the executing program is not a disk file, it will not even have a
complete path (take the Desktop for example). This is really not a
problem for most application programs.

    Leo.