[fpc-pascal] InstantFPC and argv

[Mattias Gaertner]

On Mon, 7 May 2012 13:34:50 +0200 (CEST)
"Tomas Hajny" <XHajT03 at hajny.biz> wrote:

> On Mon, May 7, 2012 12:21, Mattias Gaertner wrote:
> > On Sat, 5 May 2012 15:04:05 +0200 (CEST)
> > "Tomas Hajny" <XHajT03 at hajny.biz> wrote:
>[...]
> > The implementation for unix is only a few lines.
> > I guess for winxx and os/2 too.
> 
> 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the
> additional platform specific implementation for changing the passed
> environment).

Where do got those numbers?
TProcess for winxx only needs a few lines to set the environment:

 
> > I don't know about dos, but as fallback TProcess can be used, which
> > already implements this x-platform.
> 
> Not yet for OS/2 nor GO32v2, but yes, this would probably be a better
> option than including that stuff directly in InstantFPC if going down that
> route (of changing environment for the child process).
>  .
>  .
> >> > 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.
> 
> I understand that the preferences vary (personally, I'd probably compile
> such a bigger executable permanently).

It's not big. The RTL lacks little functions for scripts. For
example download an URL, get a list of files in a directory, load a
xml file, test a RE.

Running pascal programs as scripts is only the first step. The
next step is to provide a bunch of units that make
commons tasks one liners. That's why people use perl et al.


> Anyway, it may be useful
> occasionally and as I mentioned, solutions exist (e.g. by defining the
> interface of such modules in a way allowing to pass the location from the
> main script either directly when invoking the functions having such a need
> or indirectly by initializing the location by changing a variable declared
> within the respective unit/module at the beginning of the script, or by
> declaring the variable in the main script as external and accessing it
> from the unit).

True.
But recompilation is slow and should be avoided if possible.

Mattias