On Mon, 7 May 2012 13:34:50 +0200 (CEST) "Tomas Hajny" <xhaj...@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" <xhaj...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal