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

[Travis Siegel]

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?
If this doesn't work under all oses, is it something that could be  
fixed so it could work "properly"?
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?
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?  
I'm personally still using fpc to write terminal apps, because (as  
mentioned before) carbon apis aren't all that accessible for folks  
using voiceover, and since that's my main access to the os, I can't  
really use the ibuilder to design my interfaces, and the sample code  
for generating interface elements on the fly is spotty at best.
So, for me, this isn't as much of an issue, but I certainly do have  
some ideas where this would be extremely useful, and I'm wondering how  
much trouble it would be to get the info of the app folder, as well as  
the actual executing path.
So, feel free to pull out all the stops, spare me none of the gory  
details.  I may not understand them all, but I sure would like to see  
them anyhow.  (they will likely make sense later on).