On Sat, 5 May 2012 15:04:05 +0200 (CEST) "Tomas Hajny" <xhaj...@hajny.biz> wrote:
> On Sat, May 5, 2012 14:13, Mattias Gaertner wrote: > > On Sat, 5 May 2012 14:02:12 +0200 (CEST) > > "Tomas Hajny" <xhaj...@hajny.biz> wrote: > >> On Sat, May 5, 2012 09:22, Michael Van Canneyt wrote: > >> > On Fri, 4 May 2012, Mattias Gaertner wrote: > >> >> On Fri, 04 May 2012 17:22:16 +0200 > >> >> dhkblas...@zeelandnet.nl wrote: > >> >> > >> >>> > >> >>> > >> >>> I'm creating a script to be executed by instantfpc when I noticed > >> >>> that paramstr(0) does not reflect the location of the script but the > >> >>> location of the cached executable. Is there a way to alter this > >> >>> location > >> >>> programatically to the script location? Is there an alternative way? > >> >> > >> >> instantfpc passes as first parameter the original file name. > >> >> But execv overrides the first argument with the executed file. AFAIK > >> >> there is no alternative. > >> >> > >> >> You can set an environment variable. > >> > > >> > I think the environment variable is the best and easiest shot. > >> > >> My proposal is platform independent (i.e. it will work also under Win32, > >> OS/2, etc., without any changes). Your proposal probably requires > >> starting > >> the compiled binary using platform specific API functions to run it with > >> a > >> modified environment rather than using ExecuteProcess which results in > >> passing the standard parent's environment (changing the current's > >> process > >> environment may not be supported on all platforms). > > > > ExecuteProcess is only a simple utility function. > > All posix platforms can start a process with another > > environment. By default they use the current. > > Indeed. But InstantFPC works not only on posix platforms but also on WinXX > and OS/2 at least if I remember correctly (and there's no reason why it > couldn't be used even on Dos with e.g. 4DOS). All of them allow passing a > different environment to the child process, but the implementation is > obviously always different. That means that you need to replicate the > platform specific implementation of that 'wrapper' for all supported > platforms within InstantFPC. The implementation for unix is only a few lines. I guess for winxx and os/2 too. I don't know about dos, but as fallback TProcess can be used, which already implements this x-platform. > > A const requires to recompile the program every time you call the script > > from another location. > > You mean if calling the script with path? Yes, that's true. Passing full > path would be safer, but obviously different from ParamStr (0) behaviour. Yes. If you compile for every path change then calling the script via test.pas or ./test.pas or .//test.pas or /path/test.pas would compile 4 times. > > A const in the main script is only accessible by the program, > > not by the used units. > > There are obviously solutions for that. However, I assume that the main > use case for such scripts is writing a complete script in one file (the > main program). Many perl/php/python scripts use modules. I don't see why it should be different for fpc scripts. In fact, I already have a few shared units for my instantfpc scripts. The used units need a way to find out the current script path. Mattias _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
