Executable extension problem 1

[Péter Köves]

The way the command is invoked from an executable extension has changed between V10 and V11. Note that in Perl the variable $EXECUTABLE_NAME contains the name of the program that was used to invoke the currently running perl script as passed to the program via arguments. For the purposes of this test, the script config.pl is little more than:

use English;
print "\$EXECUTABLE_NAME=$EXECUTABLE_NAME\n";

In V10, whether invoked from an executable extension (first case) or directly using perl (second case) the value passed is the file name of the perl interpreter.

>ver
TCC 10.00.76 Windows XP [Version 5.1.2600]
>\cmd\Config\Config.pl
$EXECUTABLE_NAME=C:\perl\bin\perl.exe
>perl \cmd\Config\Config.pl
$EXECUTABLE_NAME=C:\perl\bin\perl.exe

However in V11, for the executable extension it is 'TCC'.

>ver
TCC 11.00.31 Windows XP [Version 5.1.2600]
>\cmd\Config\Config.pl
$EXECUTABLE_NAME=TCC
>perl \cmd\Config\Config.pl
$EXECUTABLE_NAME=C:\perl\bin\perl.exe

This obviously revolves around how the arguments are passed to the Windows routine that starts processes (CreateProcess if I'm not mistaken). I need to have the name of the perl interpreter in some of my scripts to ensure that child scripts are invoked with the same version of the interpreter that was used for the parent script.

 

[Jim Cook]

>> I need to have the name of the perl interpreter in some of my scripts to ensure that child scripts are invoked with the same version of the interpreter that was used for the parent script.

> Not to suggest that what you report should be looked at, but have you
> looked into $PERL_VERSION ($^V) for your test instead of
> $EXECUTABLE_NAME?

After re-reading your post, I think you may be using that to invoke a
child script yourself. If that's true, my suggestion is obviously
void. Does "do EXPR" work for you?

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.

 

[Jim Cook]

Not to suggest that what you report should be looked at, but have you
looked into $PERL_VERSION ($^V) for your test instead of
$EXECUTABLE_NAME?


2009/11/2 Péter Köves <>:

> The way the command is invoked from an executable extension has changed between V10 and V11. Note that in Perl the variable $EXECUTABLE_NAME contains the name of the program that was used to invoke the currently running perl script as passed to the program via arguments. For the purposes of this test, the script config.pl is little more than:
>
> use English;
> print "\$EXECUTABLE_NAME=$EXECUTABLE_NAME\n";
>
> In V10, whether invoked from an executable extension (first case) or directly using perl (second case) the value passed is the file name of the perl interpreter.
>
>>*ver*
> TCC *10.00.76 * Windows XP [Version 5.1.2600]
>>*\cmd\Config\Config.pl*
> $EXECUTABLE_NAME=C:\perl\bin\perl.exe
>>*perl *\cmd\Config\Config.pl*
> $EXECUTABLE_NAME=C:\perl\bin\perl.exe
>
> However in V11, for the executable extension it is 'TCC'.
>
>>*ver*
> TCC *11.00.31 * Windows XP [Version 5.1.2600]
>>*\cmd\Config\Config.pl*
> $EXECUTABLE_NAME=TCC
>>*perl \cmd\Config\Config.pl*
> $EXECUTABLE_NAME=C:\perl\bin\perl.exe
>
> This obviously revolves around how the arguments are passed to the Windows routine that starts processes (CreateProcess if I'm not mistaken). I need to have the name of the perl interpreter in some of my scripts to ensure that child scripts are invoked with the same version of the interpreter that was used for the parent script.
>
>
>
>
>
>

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.

 

[jabelli]

>ver
TCC 11.00.31 Windows XP [Version 5.1.2600]
>\cmd\Config\Config.pl
$EXECUTABLE_NAME=TCC
>perl \cmd\Config\Config.pl
$EXECUTABLE_NAME=C:\perl\bin\perl.exe

Configure TCC, turn off perl scripting, and restart TCC.

 

[Péter Köves]

Configure TCC, turn off perl scripting, and restart TCC.

Amazing! That worked, but

1. Why? This wasn't required in V10 ...
2. What exactly do I loose by turning off perl scripting? %@perl[] still seems to work ...

 

[Péter Köves]

After re-reading your post, I think you may be using that to invoke a
child script yourself. If that's true, my suggestion is obviously
void. Does "do EXPR" work for you?

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.

Basically the config.pl script is just an invoker that calls all perl scripts in a given directory whose names start with 'Config'.

I always forget about this form of 'do'. The other problem is that I'll also forget that the invoked scripts can't contain 'exit'-s (as they did now) and then it will take forever for me to figure out what is wrong. Otherwise it works with 'do'.

 

[Péter Köves]

Basically the config.pl script is just an invoker that calls all perl scripts in a given directory whose names start with 'Config'.

I always forget about this form of 'do'. The other problem is that I'll also forget that the invoked scripts can't contain 'exit'-s (as they did now) and then it will take forever for me to figure out what is wrong. Otherwise it works with 'do'.

Turns out there is a solution for this after all that allows the exit-s to be left in place: override the built in definition!

use subs 'exit';
sub exit(;$) {}

 

[rconn]

> ---Quote (Originally by jabelli)---
> Configure TCC, turn off perl scripting, and restart TCC.
> ---End Quote---
> Amazing! That worked, but
>
> 1. Why? This wasn't required in V10 ...
> 2. What exactly do I loose by turning off perl scripting? %@perl[]
> still seems to work ...

Nothing changed in the executable extensions or Perl between v10 and v11; I
suspect your problem is due to TCMD.INI differences in the Perl options.

In regards to #2, what you lose is the ability to execute Perl scripts
within the TCC process. This is useful if you want to share variables
between Perl & TCC, but if your Perl scripts are stand-alone you won't lose
anything. (Other than Perl being slightly slower to start.)

Rex Conn
JP Software