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?

Regards, Darius Blaszyk

The solution can be found on

http://www.freepascal.org/docs-html/prog/progsu38.html

Const
   ScriptName = {$INCLUDE FILE};

Michael.

Come to think of it, probably not 100% what you want. It will contain the name of the temporary script file.

Michael.

On Fri, 4 May

[3] wrote

> On Fri, 4 May 2012,

[1] 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?

> The solution can be found on

http://www.freepascal.org/docs-html/prog/progsu38.html [2] Const
ScriptName = {$INCLUDE FILE};

Come to think of it, probably not

100% what you want.

It will contain the name of the temporary script

file.

Michael. _______________________________________________

There are two parts for a possible solution. The first part should be feasible without major issues (with it still requires someone to do it, e.g. provide a patch) - InstantFPC could add the name of the original script (including full path) as a predefined constant into the Pascal source while extracting it from the original script file.

If you insist on receiving this path as ParamStr (0) result, it gets a bit more complicated. Basically, the only at least partly reasonable solution coming to my mind is having InstantFPC added a new function ParamStr locally to the script during extraction of the "temporary script" (aka Pascal source file). This overridden ParamStr function would then call System.ParamStr for all values except for ParamStr (0). This isn't much more difficult than just adding the constant described above, but it wouldn't solve cases like explicit reference to System.ParamStr (0). Also, any other RTL/FCL/... functions using ParamStr (0) (which may be in turn used from your script) would still refer to the standard System.ParamStr (0). You may not like it, but at least it wouldn't break existing standard functionality like enhanced backtraces when compiled with -gl (btw, adding the local ParamStr on a single source line would even allow these backtraces to refer to the correct line numbers from the original script file ;-) ).

Tomas

Hi Tomas,
I think your first solution would be the nicest one. If all agree and the patch would be accepted then I would like to give it shot. I'm not sure though how to insert the code in the best way. Probably it will be using passrc, although I'm not sure it will work on scripts with a shebang line.

Regards, Darius

Hi Darius,

.
.

.
.

Not sure about passrc behaviour for shebang but I believe that it may be quite easy to solve it without passrc too. I'd say that the pascal syntax knowledge necessary for this task would be limited:

1) Find the first alphabetic character after the first line (which is already processed/skipped by InstantFPC anyway) while ignoring all whitespaces and possible comments (in all allowed formats, i.e. including (* *) ) - the only small complexity here are nested comments, but even that is not so difficult to handle.

2) If there is the 'program' keyword, find the semicolon and continue searching for the next alphabetic character while still ignoring comments and whitespaces (to skip possible global compiler directives).

3) Write down 'const InstantFPCScriptName = ...;' + LineEnding immediately before the found alphabetic character (there should be no need to parse it).

Tomas

In our previous episode, Tomas Hajny said:

Will cause some "misplaced global compiler switch" if after the program came an {$mode originally.

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.

Mattias

I think the environment variable is the best and easiest shot.

Michael.

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).

Tomas

I don't think so. That's why I suggested skipping all comments in point 1 (before 'program') and also point 2 (after 'program' but before anything else) above and also mentioned global compiler directives explicitly ($mode is obviously one of them).

Tomas

http://lists.freepascal.org/mailman/listinfo/fpc-pascal

An alternative would be for instantfpc to create a temporary unit containing this constant, and inject it in the main program via the -Fa parameter. I don't know whether moving an instantfpc-based script also invalidates the cached compiled copy though (but I guess it does, because otherwise you wouldn't be able have two scripts with the same name in different locations).

Jonas

ExecuteProcess is only a simple utility function.
All posix platforms can start a process with another environment. By default they use the current.

A const requires to recompile the program every time you call the script from another location.

A const in the main script is only accessible by the program, not by the used units.

Mattias

You also have to skip the uses section.
And what about ifdefs?

Mattias

It uses only the file name, not the path to distinguish. Having two scripts with the same name recompiles every time you switch.
There is a note in the docs about that.

Mattias

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.

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.

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).

Tomas

Yes, this is a nice one. I originally thought about a unit too, but it wasn't much better without the -Fa idea (which I didn't remember).

Tomas

Yes, of course, I forgot that one, but that alone wouldn't change it much.

And what about ifdefs?

Well, right, ifdefs might make it fairly complex indeed. :-( The proposal from Jonas (temporary unit with -Fa) is obviously a better solution.

Tomas

Mattias Gaertner wrote

It uses only the file name, not the path to distinguish. Having two scripts with the same name recompiles every time you switch.

This does mean that if a script is moved, the stored script location as seen by the compiled binary will not change because it won't be recompiled, as far as I understand.

Jonas

Correct.

And it does not check if the compiler was updated or some used unit has changed.
You have to clear the cache or add the -B option to always compile.

Mattias

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.

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.

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

Mattias Gaertner wrote

On Sat, 5 May 2012 15:04:05 +0200 (CEST) "Tomas Hajny" wrote: > On Sat, May 5, 2012 14:13, Mattias Gaertner wrote:

.
.

54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the additional platform specific implementation for changing the passed 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).

.
.

I understand that the preferences vary (personally, I'd probably compile such a bigger executable permanently). 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).

Tomas

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

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.

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

Mattias

In our previous episode, Mattias Gaertner said:

I agree. I've added some minor stuff in recent versions:

- base64 encode/decode in one function (instead of streaming only)
- symbolic has a simple "quickevaluate" to quick do calculations ( like 2+4+6, even simple var substitution is possible )

I recently copied the TProcess wiki example to get the output of an exe in a string for the 3rd or 4th time, so that was my next target.

A bit like ExecuteProcess, one variant that operates on a whole cmdline (but only the most basic separation) and one array of const style.

That's why people use perl et al.

That is IMHO a bridge too far :-)

Mattias Gaertner wrote

On Mon, 7 May 2012 13:34:50 +0200 (CEST) "Tomas Hajny"

The numbers are for existing ExecuteProcess implementations (my original point was that if you needed to change the environment, you could not use ExecuteProcess as provided by the RTL and had to replicate the ExecuteProcess implementations within InstantFPC instead). Your (later) proposal to move to TProcess solves that better, of course.

.
.

.
.

<KIDDING need_to_respond=0>
Calling wget, ls or grep already are one liners. ;-) </KIDDING>

Tomas