Hi Przemek, > 2009-02-10 10:35 UTC+0100 Viktor Szakats (harbour.01 syenar hu) > > * source/rtl/filesys.c > > ! Fixes for *NIX compilation to latest change. > > Please test. [ some more ] > > It's not good idea to create code which depends on executable file > location in directory tree in systems where soft and hard links > exist. File is not directory entry in *nixes. Here directory entries > are only sth like hash tables indexed by file names which return file > i-node. The same file i-node may have many different entries in one or > more directories so you can execute the same single executable file using > different paths. It will interact with any code user can create using > hb_fsBaseDirBuff(). > Anyhow if you need such functionality then it should be implemented in > a little bit different way. The internal logic which may extract current > directory should be moved to cmdarg.c and hb_cmdargInit() function to > avoid problems with current directory changed by user code and the result > should be kept in internal buffer like s_szAppName in MS-Win builds. > Also the code which tries to create full path should be modified a little > bit. If you want I can implement it. At least we will have all such > manipulations with executable name in one place so it will be easy > to locate and change/fix if necessary.
Thanks for your suggestions, in fact I was wondering how to do that properly, and this was the closest thing I could dig up. I definitely need this, and I believe it could be of interest for other developers, as it seems needed if an app needs to access some files relative to the executable dir. Typical example: <appdir>/font/somefont.ttf. If I assume the app can be installed onto any dirs, and can be launched from any dirs, there doesn't seem to be any other ways to locate that .ttf than the help of such function. HB_PROGNAME() is very similar, but it's meant to return the (or one) absolute path of the executable, including the executable name. If you can make your proposed changes to make this robust, it'd be really great. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
