V25 eats STDERR from executable extensions

[Christian Albaret]

I have
- installed Perl: C:\Perl64\bin\Perl.exe
- D:\local\testperl.btm

C:\Perl64\bin\Perl.exe %*

- executable extension: set .pl=D:\local\testperl.btm
- testdie.pl

print "my test print message\n";
die "my test die message\n";

When I execute testdie from the command line,
- under V24 it prints

C:\Perl64\bin\Perl.exe D:\TXS\testdie.pl
my test print message
my test die message

i.e. the echo from the BTM and both messages (Perl's print goes to STDOUT, Perl's die goes to STDERR)
- under V25 it prints only

my test print message

i.e. the first message (Perl's print to STDOUT) and I don't see the second message (Perl's die to STDERR).

It seems the executable extension mechanism is involved: if I execute C:\Perl64\bin\perl.exe testdie.pl directly, without using the executable extension, I get both messages (Perl's print to STDOUT, Perl's die to STDERR).

 

[samintz]

What happens if you change the executable extension to invoke perl directly instead of via the BTM file?
e.g.

set .pl=c:\perl64\bin\perl.exe

 

[Christian Albaret]

Under V25 I also get only Perl's print message (STDOUT). Under V24 I get both messages.

 

[rconn]

Not reproducible here (nothing changed in Perl support in v25). What is "testperl.btm"?

 

[Christian Albaret]

testperl.btm is the single line (in the boiled-down example)

C:\Perl64\bin\Perl.exe %*

.
Scott Mintz pointed out that the problem is not linked to the BTM.

Your mention of "Perl support" gave me the hint: I have the problem if I activate Perl internal support (Options / TCC / Startup / Script languages, checked Perl), I don't have the problem if I uncheck Perl — same in V25 and V24 (it turns out that I usually don't change the default for Script language support, but I incidentally checked Perl internal support when I installed V25).

I don't need internal support for Perl, I run it as an external executable. The interference of Perl internal support with STDERR or a Perl external executable is obscure, but the solution is not to activate Perl internal support.

Thanks for the quick help.

 

[rconn]

I doubt this has anything to do with TCC - Perl has *lots* of problems with the Windows support. Because of the number of Windows problems with embedded Perl, TCC invokes Perl using WSH (which doesn't care about STDOUT / STDERR).

I suspect the issue is either with WSH or Perl itself - have you tried the internal Perl support on previous TCC versions?

 

[vefatica]

I don't have a Windows version of Perl installed. But, for what it's worth, this strategy seems OK (and surprisingly fast).

v:\> set .pl=v:\testperl.btm

v:\> type testperl.btm
wsl perl %@wslpath[%@truename[%1]] %2&

v:\> type testdie.pl
print "my test print message\n";
die "my test die message\n";

v:\> testdie.pl
my test print message
my test die message

v:\> testdie.pl > NUL
my test die message

v:\> testdie.pl 2> NUL
my test print message

A simpler strategy might be

set .pl=wsl perl ...

Does anyone have any ideas on getting that to work? You'd have to use @WSLPATH on the name of the .PL file, and pass the rest of the arguments. Can that be done? I don't think I can refer to %0 and %1& in the definition of an executable extension?

 

[vefatica]

In my last post I typed "%2&" where I should have typed "%2$". More elegant might be a library routine.

v:\> library /f doperl
doperl {
wsl perl %@wslpath[%@truename[%1]] %2$
}


v:\> set .pl=doperl

v:\> testdie.pl
my test print message
my test die message

v:\> testdie.pl > NUL
my test die message

v:\> testdie.pl 2> NUL
my test print message

 

[Christian Albaret]

have you tried the internal Perl support on previous TCC versions?

Once in a while but not on a regular basis. My Perl scripts tend to be very large and there is no point in having them run with internal support from TCC.
The issue is just that checking Perl internal support seems harmless but ends up with weird behavior. Ideally something should tell that asking for Perl internal support and then running Perl external executable will cause havoc — but this would need some wizardry.