[fpc-pascal] Re: specifying the relative path to a file that is located in the same folder as the application bundle?

[Jonas Maebe]

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.