Perl and tcc (redux)

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
(Still running TCC 15.01.52 x64 under Windows 7)

I know I've brought this up already but maybe I didn't ask the right questions...still baffled. If I associate .pl (the extension for Perl scripts) with perl.exe, simply typing scriptname.pl at the command prompt -- if it's cmd.exe -- launches Perl, runs the script, and passes along any command-line arguments.

As we've discussed before, this only generates an error under TCC. Instead, you have to type perl scriptname [arguments]. That is: start by launching perl itself.

That by itself is no particular hardship. But if the Perl script returns exit codes, it's impossible to capture them via some other process, the reason being that Perl.exe itself typically returns exit code 0 when there's a successful execution of the script. Any non-zero exit codes the script returns are never "visible".

If the script is launched like this:

cmd.exe /c scriptname [arguments]

Then its exit codes can be captured.

But any attempt to associate something with ".pl" -- perl.exe, start perl.exe, start /pgm perl.exe, cmd.exe /c, cmd.exe /c perl.exe -- etc., etc. -- all fail, with Perl printing the error message Error (SYS): Invalid class string.

What is making the difference here? Is it some Secret Sauce that cmd.exe has, enabling it to launch these kinds of scripts without error?

(It's 32-bit ActivePerl running on a 64-bit machine. 64-bit Perl does not seem terribly stable to me and does not have a sterling reputation.)
 
Jan 3, 2012
25
4
UK
#2
I have what may be a related problem, although the circumstances are different.

I recently upgraded from TCC 9.02 to TCC 16.02.48 x64 on Windows 7. I have 64-bit ActiveState Perl v.5.12.4 (with which I have no (other) problems). So I'm running 64-bit Perl in 64-bit TCC.

My executable extension .pl works as expected in TCC 9. But entering the name of a perl script on a TCC.16 x64 command line apparently has no effect. This is regardless of whether the Perl Scripting option is selected or deselected.

In 16.02.48 x64:
-- 8<-----------------------------------------------------------------------
[z:] ver /r

TCC 16.02.48 x64 Windows 7 [Version 6.1.7601]
TCC Build 48 Windows 7 Build 7601 Service Pack 1

[z:] set .pl
C:\perl64\bin\perl.exe

[z:] which try.pl
try.pl is an executable extension : C:\perl64\bin\perl.exe [...]\try.pl

[z:] type try.pl
print "OK\n" ;

[z:] try.pl

[z:] perl try.pl
OK
-- 8<-----------------------------------------------------------------------


In TCC 9.02:
-- 8<-----------------------------------------------------------------------
[z:] set .pl
C:\perl64\bin\perl.exe

[z:] which try.pl
try.pl is an executable extension : C:\perl64\bin\perl.exe [...]\try.pl

[z:] type try.pl
print "OK\n" ;

[z:] try.pl
OK


[z:] perl try.pl
OK
-- 8<-----------------------------------------------------------------------
 

samintz

Scott Mintz
May 20, 2008
1,232
11
Solon, OH, USA
#3
I get the same results in TCCx64 16.02.48. I am using 32 bit ActiveState Perl v5.8.7 and running Win7x64.

I tried adding .PL to PathExt and enabling PathExt in the OPTION dialog. I tried adding a .PL executable extension. And I have Windows associations for .PL. The only thing that produces output is prefacing the script with PERL (i.e. perl try.pl).

There is something special about the Perl (.pl) extension. If I rename the file to TRY.PRL, and change my executable extension to SET .PRL=perl, then I get the expected behavior.

The help file states:
You must enable Perl support in the OPTION / Startup page. If it is enabled, TCC will automatically load Perl on your system. If a suitable library is found, TCC checks to see if you are running a .PL file. If so, TCC passes the file to your Perl interpreter for processing.

So there must be some kind of special processing for .PL files.
 
#4
Scott, I was able to get exactly the results you've reported after I created a value for .prl and had renamed 'test.pl' temporarily to 'test.prl'. Typing the script's name alone executed it, as expected. How downright interesting. So what IS it about that '.pl' extension? Kudos to you for having tried this. I'd never have thought of it. Too bad there's no "I know it says '.pl' in the filename, but pretend it's '.prl' for just a moment" option... :-)