Embedded perl and stdout?

[vefatica]

Perhaps naively, I expected output from a .PL script, run by TCC's embedded perl, to go to stdout. But it doesn't seem to do so. Below, when I run it with PERL.EXE I can pipe it's output; when I let TCC run it, I can't.

v:\> type embedded.pl
printf("%s\n%s\n", "Hello", "world!");

v:\> perl embedded.pl | wc
  Lines   Words   Chars
      2       2      15

v:\> embedded.pl | wc
  Lines   Words   Chars
Hello
world!
      0       0       0

 

[LarryBrasfield]

I'm not reproducing what you saw.
On TCC v23.00.24, Windows 10, with ANSI handling at installation defaults, with TCC in a TCMD tab, I get:

[C:\Tmp]
> copy clip: embedded.pl
clip: => C:\Tmp\embedded.pl
     1 file copied

[C:\Tmp]
> embedded.pl
Hello
world!

[C:\Tmp]
> embedded.pl | wc
      2       2      15

[C:\Tmp]
> perl embedded.pl | wc
      2       2      15

[C:\Tmp]
> wc --version
wc (GNU coreutils) 5.3.0
Written by Paul Rubin and David MacKenzie.

Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[C:\Tmp]
>

 

[vefatica]

I'm not reproducing what you saw.

Are you using embedded Perl (OPTION\Startup\Scripting\Perl checked)? I am.

If I use instead, the registry .PL association, or an executable extension (set .pl=perl) piping works as expected.

v:\> which embedded.pl
embedded.pl is associated with : G:\Perl\bin\perl.exe

v:\> embedded.pl | grep orl
world!

v:\> set .PL=perl

v:\> which embedded.pl
embedded.pl is an executable extension : perl V:\embedded.pl

v:\> embedded.pl | grep orl
world!

v:\> unset .pl

v:\> option //Perl=Yes

v:\> embedded.pl | grep orl
Hello
world!

 

[LarryBrasfield]

After setting that option, I get the same results that you did.

Previously, I never set it because I could not see what it would do for me. (Perl starts, compiles and runs fast on my systems.)

Now, I think I will not use it because I do not understand it and because I like the way it works without that option.

What benefit, aside from possible startup latency, is there to using that option?

 

[rconn]

Perhaps naively, I expected output from a .PL script, run by TCC's embedded perl, to go to stdout. But it doesn't seem to do so. Below, when I run it with PERL.EXE I can pipe it's output; when I let TCC run it, I can't.

This shouldn't come as a surprise to you -- TCC doesn't use embedded Perl (perlxx.dll) because of your (numerous) bug reports several years ago about the massive memory leaks and broken break handling in embedded Perl. TCC uses PerlScript (WSH), which doesn't support redirection (though TCC does pass it the redirected STDxxx handles).

 

[vefatica]

I don't recall the memory leak business and couldn't come up with anything by searching the forums. As for the break handling, it's still a problem. I'm referring to either using @PERL[] or running *.PL with OPTION //Perl=Yes. While either is in progress, pressing Ctrl-C causes TCC to vanish. And after either has finished, X-ing the console results in

TCC has stopped working

  Problem Event Name:    APPCRASH
  Application Name:    tcc.exe
  Application Version:    23.0.24.0
  Application Timestamp:    5b41100b
  Fault Module Name:    Perl522.dll
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    599f96cf
  Exception Code:    c0000005
  Exception Offset:    0013408d
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    1033

 

[rconn]

I don't recall the memory leak business and couldn't come up with anything by searching the forums. As for the break handling, it's still a problem. I'm referring to either using @PERL[] or running *.PL with OPTION //Perl=Yes. While either is in progress, pressing Ctrl-C causes TCC to vanish. And after either has finished, X-ing the console results in

Perhaps you'd like to send the Perl developers a gentle reminder that their Windows port is crap?

 

[LarryBrasfield]

Rex, I am puzzled by your explanation (to Vince) that WSH does not support redirection (though TCC passes redirected STDxx handles.) If it gets redirected standard handles from a parent process, is that not all that is needed for redirection to occur? (That's the model I've long had, and it has seemed quite predictive.)

Furthermore, as far as I can tell, cscript.exe (in the %windir\system32 directory, part of "Windows Script Host Version 5.812") does support redirection. To wit:

> cscript seetabs.pl //E:PerlScript //Nologo >overtab.txt

> type overtab.txt
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
        |       |       |       |       |       |       |       |       |       |       |       |   |   |       |       |       |       |       |       |

>

Vince's results, and your declaration that we should expect to see nothing emitted in his second case, makes me wonder all the more what the benefit is supposed to be to using TCC's Perl support. As far as I can tell, there are no data pathways out of the PerlScript engine (when used by TCC) other than files (or named pipes), IPC, registry entries, and other unusual means.

 

[vefatica]

As far as I can tell, there are no data pathways out of the PerlScript

You can include the environment there also, and this really bewilders me. Consider this script.

v:\> type ement.pl
sleep(3);
printf("%s\n", $ENV{foo});
$ENV{foo} = "22";
printf("%s\n", $ENV{foo});
sleep(3);

If I do this (below) I see that TCC's environment variable "foo" has not changed.

v:\> option //Perl=Yes

v:\> set foo=bar

v:\> ement.pl
bar
22

v:\> echo %foo
bar

If I snoop on TCC's envvar "foo" using SETP in another TCC ... it doesn't change, not even temporarily.

No new processes were created. So whose environment was the script tinkering with?

That's in sharp contrast to PERL.EXE executing the script. Snooping with SETP I do see PERL.EXE's environment change.

 

[LarryBrasfield]

(To Rex:)

I surmise that when you say "WSH does not support redirection", what you mean is that the IActiveScript interface has no provision for redirecting standard I/O that may be done by the engine when it runs a script. I suppose that is true if the interface is to an out-of-process object. But it is not true for the common case where the engine is running in the same process as the interface's client. In that case, SetStdHandle(), called by the client that instantiated the in-process engine, should cause the specified (in,out,error) stream(s) to be redirected. The standard handles the client started with can be restored via SetStdHandle calls after the engine notifies the client that the script has completed.

If you doubt this, consider: Why, when cscript (or wscript) is run with against a script that produces standard output, when that is left directed to the console, are characters appearing on the console?