TCC and clipboard issue

[mikea]

TCC 11.00.47, running under Windows 7

I continue to have odd problems with the clipboard. I had thought they were fixed, but they're back.

echo some string>clip:
echo some other string>>clip:

...works. But if I run a Perl script:

scriptname.pl [arguments] > clip:

...the output -- even if it is EXPLICITLY sent to STDOUT in the script -- is displayed at the terminal, and nothing goes into the clipboard.

If I run cmd.exe and do this:

scriptname.pl [arguments] | clip.exe

... the output gets into the clipboard, as expected.

What am I doing wrong here? This never failed under 4NT...

Maybe I need to update TC/TCC again? I haven't done it for a while. Do I need to uninstall/re-install? Or just download the latest version, run it, and point it at the same directory where it's installed now? (With no TCC command line open at the time, of course.)

 

[rconn]

> I continue to have odd problems with the clipboard. I had thought they
> were fixed, but they're back.
>
> echo some string>clip:
> echo some other string>>clip:
>
> ...works. But if I run a Perl script:
>
> scriptname.pl [arguments] > clip:
>
> ...the output -- even if it is EXPLICITLY sent to STDOUT in the script
> -- is displayed at the terminal, and nothing goes into the clipboard.

Assuming you're running Perl within TCC (i.e., you've checked Perl support
on the TCC OPTION Startup/Scripting section, then the problem you're seeing
is a (known, old) Perl bug.

> If I run cmd.exe and do this:
>
> scriptname.pl [arguments] | clip.exe
>
> ... the output gets into the clipboard, as expected.

This would be the same as unchecking Perl in the TCC OPTION dialog, so Perl
scripts are executed by the perl.exe rather than internally via the (buggy)
Perl dll.

Rex Conn
JP Software

 

[mikea]

Assuming you're running Perl within TCC (i.e., you've checked Perl support
on the TCC OPTION Startup/Scripting section, then the problem you're seeing
is a (known, old) Perl bug.

Then the workaround is to un-check that box? (I just looked at it -- at the moment it's checked.)

Is it required to have that box checked to run Perl scripts when TCC is being used? If so: what is the specific purpose or effect of explicitly selecting Perl support in the TCC option dialog?

Putting it another way: what is the expected result of running Perl scripts with the box UN-checked? I'm going to try that immediately, but it'd be good to know what adverse effects (if any) I should expect.

If it's a known Perl bug: it never appeared, that I can recall, when I launched Perl scripts in a 4NT window. I must have done so thousands of times over the many years that I used 4NT.

And, this variation on the theme works within a TCC window:

cmd /c scriptname.pl [args] > clip:​

Now the clipboard contains the output of the script. But remove "cmd /c" from the command, and it doesn't work again...

 

[mikea]

A few minutes later . . . the clipboard problem stopped once I'd un-checked the Perl option in the OPTION dialog. Thanks for the advice about it. I didn't even remember that I'd checked the box...

So back to my previous question: what is the expected/desired functionality that is available, when the box is checked? Is it limited to being able to use TCC's @perl[] function? The script I ran after unchecking that selection -- didn't seem to have been impaired in any way.

Actually, with the box UNchecked I was still able to execute:

echo %@perl[print "hello"]

I'd have thought that un-selecting that option would render the %@perl[] function unusable. So clearly I don't yet understand the purpose of that little check-mark...

 

[rconn]

> Is it required to have that box checked to run Perl scripts when TCC is
> being used? If so: what is the specific purpose or effect of explicitly
> selecting Perl support in the TCC option dialog?

It is not required. Checking the box means that Perl scripts will be
executed within the TCC process, so you can set environment variables in
Perl that are then readable by TCC. Execution will also be slightly faster,
though probably not noticeable.

The problem is that Embedded Perl for Windows was not well designed or
implemented, and there are a number of bugs (such as this redirection
problem and ^C exception handling) that have been known & not fixed for
years. (The embedded Python, Ruby, Rexx, and Tcl support in TCC do not have
these problems.)

Rex Conn
JP Software

 

[mikea]

The problem is that Embedded Perl for Windows was not well designed or implemented, and there are a number of bugs (such as this redirection problem and ^C exception handling) that have been known & not fixed for years. (The embedded Python, Ruby, Rexx, and Tcl support in TCC do not have these problems.)
Rex Conn
JP Software

This is an issue with ActiveState's Perl implementation? (That's the only one I use, v.5.10 at the moment, FWIW.)

If not ActiveState's: I recall having seen a non-ActiveState perl.exe in older o.s. versions I used. But at least on my home machine, under Win XP SP2, I don't find perl.exe either in %windir or %programfiles.

 

[rconn]

> This is an issue with ActiveState's Perl implementation? (That's the
> only one I use, v.5.10 at the moment, FWIW.)

Yes.

Rex Conn
JP Software