Travis Siegel wrote on vr, 06 feb 2009:
On Feb 5, 2009, at 4:00 PM, Jonas Maebe wrote:
On 05 Feb 2009, at 22:52, Paul Nicholls wrote:
MyProgramFolder := ExtractFilePath(ParamStr(0));
This should hopefully get you the folder of the currently running program
from within the program (at least under Win32 and Linux).
That is completely OS (and sometimes OS-version) dependent, and
should not be used if you want portable code (even on Linux it does
not work under all circumstances).
Ok, now I'm curious.
Why doesn't this work? is it because of the way shells interpret
currently running program? or is there something related to process ids
or something?
It is related to the fact that on Unix-like platforms the concept of
*the* path to an executable does not exist (there can be multiple hard
links all pointing to the same binary), an underlying directory can be
renamed after a program has been started (so the path is no longer
valid), the binary can be deleted while it is running (then it still
exists on disk until the binary quits), etc.
In a sense, this is no problem because on Unix-like platforms you are
not supposed to use the fact where a binary is located in the first
place. You should only use the directory where the user was when the
binary was started (the present working directory), hard-coded paths
(e.g., relative to the system root, and relative to the user's home
directory), and paths inside configuration files stored in those
directores.
In case of bundled apps on Mac OS X this is different, which is why
there are special API's in that case to resolve the location of the
application bundle.
If this doesn't work under all oses, is it something that could be
fixed so it could work "properly"?
No. We can make it work in many cases (which is what is currently done
on Linux), but since no guarantees are offered by the OS, this is
bound to break in rare cases or with new OS releases.
For example, if a program is started using a symbol link, older Linux
kernels used to report the file pointed to by this symbolic link.
Newer kernels report the symbolic link itself. The result is that
FPC-compiled programs relying on getting the actual binary location
will break when run on newer kernels (until another kludge is added to
also resolve these symbolic links, after which we can wait until the
next change that breaks this system).
And in no case the problems I mentioned at the start of this mail can
be fully resolved. Also, if the OS only reports the command line as it
was entered by the user (after resolving aliases), you have to start
figuring out the used shell, the associated PATH, the used algorithm
to determine which binary the shell will then pick, etc.
I'm not all that familiar with internal os complexities, though I do
seem to be drawing closer to that mark these days, but this seems to me
to be an extremely important thing to know, and if fpc could be patched
to provide this bit of info, shouldn't it be done?
That has been done to a certain extent, but that does not mean that it
is a good idea to rely on this information for anything but displaying
information. For older Mac OS X releases, we'd have to follow the
whole "do whatever we think the shell may have done"-routine. 10.5
reports "a" full path, but as mentioned it's unadvisable to rely on it
being useful.
How much troube would this be on an os like OSX for instance, where the
app bundle isn't necessarily the same as the application itself?
When using app bundles, use the bundle api's. When not using an app
bundle, follow the standard Unix conventions and do not count in any
way on being able to figure out where your binary is located.
Jonas
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
