redirection to/by perl acts bizarrely

[LarryBrasfield]

As I frequently do, I tried to run a perl script that gets
all its input from STDIN and sends its outputs to
STDOUT and STDERR (for exceptional or error output).
Doing that under TCC v11 appears to be broken. (I've
looked for 20 minutes in the docs and searched the
support forum for mention of this, and do not see it.
So I still imagine this is not by-design behavior. If it
is by design, I will be pretty much abandoning use of
the tabbed console gizmo.)

The attached session screen scrapes show the running
of the script under TCC v11, where input is putatively
redirected to the running perl process, and it attempts
to write to the usually defined/opened output streams.
None of them are connected. The process waits around
for me to type at it, and the outputs all go to the
console instead of to the files to which they were (or
should have been?) redirected.

The last scrape shows TCC/LE v11 doing exactly what
I expect and would like TCC to do.

If this is a WAD issue, I have to say that the help that
comes up has either nothing to say about this behavior
or what it does say it obscurely hidden.

This problem occurs only in the "Take Command"
application, v11.00.44 . Running TCC in a system-
provided console window works just as expected.

Thanks,
Larry Brasfield

 

[Jim Cook]

I don't get your behavior, unless I've tried to reproduce the problem badly.
I am using a TCC window within TCMD. It does seem to behave the same way
both inside the tab, and detached. It behaves the same way with and without
the .pl extension provided.


D:\RedirBug>*dir /k /m /h
2010-03-23 10:24 76 splitmunge.pl
2010-03-23 10:24 27 stuff.txt

D:\RedirBug>type splitmunge.pl
while ($_ = <>) {
print STDOUT "out: $_";
print STDERR "err: $_";
}

D:\RedirBug>type stuff.txt
cat
dog
meowser
barker

D:\RedirBug>splitmunge.pl < stuff.txt > out.txt 2> err.txt

D:\RedirBug>*dir /k /m /h
2010-03-23 10:27 47 err.txt
2010-03-23 10:27 47 out.txt
2010-03-23 10:24 76 splitmunge.pl
2010-03-23 10:24 27 stuff.txt

D:\RedirBug>type err.txt
err: cat
err: dog
err: meowser
err: barker

D:\RedirBug>type out.txt
out: cat
out: dog
out: meowser
out: barker

D:\RedirBug>ver /r

TCC 11.00.44 Windows XP [Version 5.1.2600]
TCC Build 44 Windows XP Build 2600 Service Pack 3


D:\RedirBug>*which perl
perl is an external : R:\PERL\BIN\perl.exe

D:\RedirBug>perl -v

This is perl, v5.8.0 built for MSWin32-x86-multi-thread


On Tue, Mar 23, 2010 at 8:58 AM, LarryBrasfield <>wrote:

> As I frequently do, I tried to run a perl script that gets
> all its input from STDIN and sends its outputs to
> STDOUT and STDERR (for exceptional or error output).
> Doing that under TCC v11 appears to be broken. (I've
> looked for 20 minutes in the docs and searched the
> support forum for mention of this, and do not see it.
> So I still imagine this is not by-design behavior. If it
> is by design, I will be pretty much abandoning use of
> the tabbed console gizmo.)
>
> The attached session screen scrapes show the running
> of the script under TCC v11, where input is putatively
> redirected to the running perl process, and it attempts
> to write to the usually defined/opened output streams.
> None of them are connected. The process waits around
> for me to type at it, and the outputs all go to the
> console instead of to the files to which they were (or
> should have been?) redirected.
>
> The last scrape shows TCC/LE v11 doing exactly what
> I expect and would like TCC to do.
>
> If this is a WAD issue, I have to say that the help that
> comes up has either nothing to say about this behavior
> or what it does say it obscurely hidden.
>
> Thanks,
> Larry Brasfield
> to
>
> Attached to this message is redirbug.txt (
> http://jpsoft.com/forums/attachment.php?attachmentid=121&d=1269359241)<br>
>
>
>

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[LarryBrasfield]

Thanks, Jim, for trying to replicate that.
Strangely, with a fresh TC process running and
a few memory-intensive other applications shut
down, I don't get my behavior either. I'll have
to keep an eye out for it in case the triggering
condition becomes apparent. I imagine Rexx
has enough to do without worrying about bugs
that rarely manifest, or maybe not on his machines.

Cheers,
--
Larry Brafield

I don't get your behavior, unless I've tried to reproduce the problem badly.
I am using a TCC window within TCMD. It does seem to behave the same way
both inside the tab, and detached. It behaves the same way with and without
the .pl extension provided.
...
--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[rconn]

> As I frequently do, I tried to run a perl script that gets
> all its input from STDIN and sends its outputs to
> STDOUT and STDERR (for exceptional or error output).
> Doing that under TCC v11 appears to be broken. (I've
> looked for 20 minutes in the docs and searched the
> support forum for mention of this, and do not see it.
> So I still imagine this is not by-design behavior. If it
> is by design, I will be pretty much abandoning use of
> the tabbed console gizmo.)
>
> The attached session screen scrapes show the running
> of the script under TCC v11, where input is putatively
> redirected to the running perl process, and it attempts
> to write to the usually defined/opened output streams.
> None of them are connected. The process waits around
> for me to type at it, and the outputs all go to the
> console instead of to the files to which they were (or
> should have been?) redirected.
>
> The last scrape shows TCC/LE v11 doing exactly what
> I expect and would like TCC to do.

Not reproducible here; TCC standalone and TCC in a TCMD tab window behave
the same and give the same output as TCC/LE. (Not surprising, as the
redirection code is exactly the same in TCC and TCC/LE.)

Are you running the internal Perl support (with Perl selected in the
Scripting section on the OPTION / Startup page), or by running the external
Perl.exe?

Rex Conn
JP Software

 

[LarryBrasfield]

Hi, Rex.

It's not reproducible here, either, at least not with
the simple try-again approach. I've been keeping
the Perl scripting option off while I develop scripts
for others to use. That was the case when this bug
or temporary system aberration showed up. The
misbehavior does not reoccur whether the 'Perl'
scripting checkbox is checked or not. What I can
offer on it is this: At the time, I had evidence of
available memory stress. (I use an application
which handles that very badly, and it has taught
me to relieve the stress by closing some other apps
that grab a lot of memory. Even explorer.exe is in
that category, refusing to run file-open dialogs.)

Best regards,
Larry

Not reproducible here; TCC standalone and TCC in a TCMD tab window behave
the same and give the same output as TCC/LE. (Not surprising, as the
redirection code is exactly the same in TCC and TCC/LE.)

Are you running the internal Perl support (with Perl selected in the
Scripting section on the OPTION / Startup page), or by running the external
Perl.exe?

Rex Conn
JP Software

 

[LarryBrasfield]

This problem, or something close to it, is now
reproducing here. (I'm hesitant to admit it, but
I think I might have not shutdown all instances
of TCC when fiddling with Perl scripting option
before.) Now, if that option has been checked
before shutting down all TCC instances, then
(after starting a lone instance and) running
whatever < somefile.txt
where a file named whatever.pl is first findable
in my %PATH, and set shows
.pl=@perl
(among much else) and ActiveState's perl.exe
is also found first in my %PATH, causes Perl to
be given the console keyboard as STDIN rather
than an open file stream. This occurs with TCC
running in its own, system-provided console
window, or in a TC console tab window. Here
are some context indicators and a problem demo:

=== with 'Perl' scripting checked and TCC restart===

[C:\Work\Verasonics\Simulations]
> which perl
perl is an external : C:\Programs\Perl\bin\perl.exe

C:\Work\Verasonics\Simulations]
> perl -v

This is perl, v5.10.1 built for MSWin32-x86-multi-thread
(with 2 registered patches, see perl -V for more detail)

Copyright 1987-2009, Larry Wall

Binary build 1007 [291969] provided by ActiveState http://www.ActiveState.com
Built Jan 26 2010 23:15:11
...

[C:\Work\Verasonics\Simulations]
> which tsvpp
tsvpp is an executable extension : @perl C:\Bin\tsvpp.pl

[C:\Work\Verasonics\Simulations]
> set .pl
@perl

[C:\Work\Verasonics\Simulations]
> tsvpp < aa_diff_vdasV1.out_fr.tab
^Z

[C:\Work\Verasonics\Simulations]
> rem control-Z is to end keyboard sucking.

=== after 'Perl' scripting unchecked and TCC restart===

[C:\Work\Verasonics\Simulations]
> tsvpp < aa_diff_vdasV1.out_fr.tab
frequency V(aaf_out)
+1.0000e+005+0.0000e+000j -1.9716e-001+2.2790e-001j

===================================

I'm running TCC 11.00.44, BTW.
--
Larry

Not reproducible here; TCC standalone and TCC in a TCMD tab window behave
the same and give the same output as TCC/LE. (Not surprising, as the
redirection code is exactly the same in TCC and TCC/LE.)

Are you running the internal Perl support (with Perl selected in the
Scripting section on the OPTION / Startup page), or by running the external
Perl.exe?

Rex Conn
JP Software

 

[rconn]

> This problem, or something close to it, is now
> reproducing here. (I'm hesitant to admit it, but
> I think I might have not shutdown all instances
> of TCC when fiddling with Perl scripting option
> before.) Now, if that option has been checked
> before shutting down all TCC instances, then
> (after starting a lone instance and) running
> whatever < somefile.txt
> where a file named whatever.pl is first findable
> in my %PATH, and set shows
> .pl=@perl
> (among much else) and ActiveState's perl.exe
> is also found first in my %PATH, causes Perl to
> be given the console keyboard as STDIN rather
> than an open file stream.

If you're using the internal TCC Perl support, you cannot use redirection.
This is a bug/feature lack in the embedded Perl code, not TCC; there's
nothing I can do about it. (Well, short of rewriting embedded Perl, which
certainly is in desperate need of repair!)

Rex Conn
JP Software

 

[rhubarb]

I have a similar problem - perhaps not the same but related to perl, redirection and tccle.
the odd thing is I only started seeing this problem a couple of weeks ago. It was at the same time as I began trying different options to work around another problem but I can't think of what I changed to cause this. Perhaps it was an update.
In any case here's the issue. I use a perl script for building which I've been using for many years. I checked its svn history and it hasn't been changed lately. The key part is in a command which does java compilation. It is launched like this in a perl script:

system("$cmd 2>&1");

where $cmd expands (in perl v5.14.2) to the java compile line.

Here's what happens when the perl script is run:

1. In TCC/LE (13.06)
Nothing: it issues the command but there appears to be no result. The compilation does not occur.

2. In windows CMD.exe
It works - it compiles the java file.

3. Now If I change the perl statement to this:
system("$cmd");
removing the redirection, it now works in TCC/LE.
The command executes and compiles
Being LE, the script options are turned off - so it's not using embedded perl. It's using active perl which I installed separately.
Any ideas?

 

[rhubarb]

Nevermind - I just reproduced the same problem in a cmd.exe window. Weird - haven't solved it yet, but TCC/LE is clearly off the hook (in both senses :)

 

[epement]

Nevermind - I just reproduced the same problem in a cmd.exe window. Weird - haven't solved it yet, but TCC/LE is clearly off the hook (in both senses :)

I believe the problem you're experiencing is caused by improper syntax for the perl system() command.
The syntax should be: system("program-name", "redirection-argument");

Try running perldoc -f system and note the statement:

If there is only one scalar argument [following the program name],​

the argument is checked for shell
metacharacters, and if there are any, the entire argument is
passed to the system's command shell for parsing (this is
"/bin/sh -c" on Unix platforms, but varies on other platforms).​

​

​

Hope this helps.​