V25 eats STDERR from executable extensions

I have
- installed Perl: C:\Perl64\bin\Perl.exe
- D:\local\testperl.btm
Code:
C:\Perl64\bin\Perl.exe %*
- executable extension: set .pl=D:\local\testperl.btm
- testdie.pl
Code:
print "my test print message\n";
die "my test die message\n";
When I execute testdie from the command line,
- under V24 it prints
Code:
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
Code:
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).
 
  • Like
Reactions: Charles Dye

samintz

Scott Mintz
May 20, 2008
1,421
13
Solon, OH, USA
What happens if you change the executable extension to invoke perl directly instead of via the BTM file?
e.g.
Code:
set .pl=c:\perl64\bin\perl.exe
 
testperl.btm is the single line (in the boiled-down example)
Code:
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

Administrator
Staff member
May 14, 2008
11,926
133
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?
 
May 20, 2008
10,623
81
Syracuse, NY, USA
I don't have a Windows version of Perl installed. But, for what it's worth, this strategy seems OK (and surprisingly fast).

Code:
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

Code:
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?
 
May 20, 2008
10,623
81
Syracuse, NY, USA
In my last post I typed "%2&" where I should have typed "%2$". More elegant might be a library routine.

Code:
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
 
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.