WinNT ActiveState STDERR and STDOUT

[addinall]

I'm having a problem and wondered if anyone else
has come across something like this.

I have a customer with a legacy NT4.0 system.
A requirement came up to run several jobs in
the background and capture the output of STDOUT
and STDERR for later analysis.

Code (example only)

HELLO.BAT
echo Hello World this is STDOUT
This line will produce an error to STDERRR
echo

posix.pl
#! perl -w

use Proc::Background qw( timeout_system ) ;
print("Hello World STDOUT from Perl") ;
my @t = timeout_system( 5, "c:\\Perl\\bin\\HELLO.BAT") ;
die("STDERR from Perl") ;

POSIX.BAT
perl posix.pl >log 2>&1

This gets

log
STDERR from Perl
Hello World STDOUT from Perl

But nada, zip, from the process that has been backgrounded.

This is NT4 service pack six
Active Perl-5.8.8.817 for MSWin32-x86-multi-thread.

Any ideas? I'm a UNIX head, so windows is a little
strange for me. POSIX should let you do this.

Cheers,
Mark Addinall.

 

[Thomas Kratz]

I'm having a problem and wondered if anyone else
has come across something like this.

I have a customer with a legacy NT4.0 system.
A requirement came up to run several jobs in
the background and capture the output of STDOUT
and STDERR for later analysis.

Code (example only)

HELLO.BAT
echo Hello World this is STDOUT
This line will produce an error to STDERRR
echo

posix.pl
#! perl -w

use Proc::Background qw( timeout_system ) ;
print("Hello World STDOUT from Perl") ;
my @t = timeout_system( 5, "c:\\Perl\\bin\\HELLO.BAT") ;

As I understand from a quick glance at the docs for Proc::Background,
background processes are created through Win32:rocess::Create like this:

Win32:rocess::Create(
$os_obj,
$args[0],
"@args",
0,
NORMAL_PRIORITY_CLASS,
'.'
);

The 0 as 4th parameter means "don't inherit handles from callin process",
which means this process will not inherit STDOUT and STDERR from perl or
eventually the shell your script is running in.

Change this to use the standard system() function and it will.

But you can specify a different log file as

my @t = timeout_system( 5, 'c:\Perl\bin\HELLO.BAT >log2 2>&1') ;

Or you could file a change request to the author of Proc::Background to
make the flag configurable.

Thomas

--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-

 

[addinall]

I'm having a problem and wondered if anyone else
has come across something like this.

I have a customer with a legacy NT4.0 system.
A requirement came up to run several jobs in
the background and capture the output of STDOUT
and STDERR for later analysis.

Code (example only)

HELLO.BAT
echo Hello World this is STDOUT
This line will produce an error to STDERRR
echo

posix.pl
#! perl -w

use Proc::Background qw( timeout_system ) ;
print("Hello World STDOUT from Perl") ;
my @t = timeout_system( 5, "c:\\Perl\\bin\\HELLO.BAT") ;

As I understand from a quick glance at the docs for Proc::Background,
background processes are created through Win32:rocess::Create like this:

Win32:rocess::Create(
$os_obj,
$args[0],
"@args",
0,
NORMAL_PRIORITY_CLASS,
'.'
);

The 0 as 4th parameter means "don't inherit handles from callin process",
which means this process will not inherit STDOUT and STDERR from perl or
eventually the shell your script is running in.

Change this to use the standard system() function and it will.

Can I specify a timeout under system()? I have read the code and it
doesn't seem so.

But you can specify a different log file as

my @t = timeout_system( 5, 'c:\Perl\bin\HELLO.BAT >log2 2>&1') ;

Thanks for your response. I really appreciate it.
I tried fudging it to a different log file (before I read this
actually) and it seems that under this particular OS (NT4)
NO file redirection works under a process that has dup()ed
a handle. log2 doesn't even get created... Grrrr.....

It all seems to work fine under Windows 2000, yet to test 2003,
although like I mentioned, Windows is a whole new ball game
for me.

Or you could file a change request to the author of Proc::Background to
make the flag configurable.

I might make that suggestion. Perhaps at the same time we could
make the priority flag configurable as well? It would be good
for me, bad for fork() bombs!

Thanks for your time.

Mark.

Thomas

--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-

 

[Ben Morrow]

Thanks for your response. I really appreciate it.
I tried fudging it to a different log file (before I read this
actually) and it seems that under this particular OS (NT4)
NO file redirection works under a process that has dup()ed
a handle. log2 doesn't even get created... Grrrr.....

AFAIK the POSIXish redirection operators don't work at all under NT4. I
would recommend you build something yourself out of Win32:rocess; not
a terribly pleasant task ...

Ben