[fpc-pascal] InstantFPC and argv

[Mattias Gaertner]

On Sat, 5 May 2012 15:04:05 +0200 (CEST)
"Tomas Hajny" <XHajT03 at 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" <XHajT03 at 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
> >> >> dhkblaszyk at 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