rovf:

I think that the problem you're having is that the perl executable doesn't manage I/O redirection. Normally that's handled by the shell. So the command you're giving doesn't actually try to redirect STDOUT and STDERR--instead it's just passing ">out.txt" and "2>&1" as arguments to the myProg.pl script.

Why not simply add command-line options to myProg.pl to have alternate output streams? Then you don't have to detect redirection--you just tell myProg where to send the output.

...roboticus

BTW, I double-checked the perldocs. The case about no redirection performed is documented there, but only for the implementation on RISC OS. About Windows, this restriction is not mentioned. Actually, the docs don't say anything at all about the Windows implementation.

However, I now found a reproducible case where the problem appear. What surprises me is the fact that it looks so simple:

...
system(1,'perl.exe',$0,'SLAVE1','>out1.txt','2>&1');
...
[download]

Here I found that the redirection is never set up, and indeed if I do a -t STDOUT in the child process, I always get a true value. Now it puzzles me why we have in our application so many cases which work. My best guess is that Perl, in those cases, finds something which makes it create an intermediate CMD.EXE process which sets up the redirection.

(Just in case you wonder: The reason why I call myself recursively via $0 is that my test program distinguishes by its first parameter whether it should act as a child instead as a parent).

-- 
Ronald Fischer <ynnor@mm.st>

I think that the problem you're having is that the perl executable doesn't manage I/O redirection.

This can't be correct, for two reasons: If it were the case, the error should occur all the time (and not only occasionally), and @ARGV in the child process would have the "redirection parameters".

Actually, no shell isn't involved in this particular case. Redirection is performed in this case by the calling process, by system(1,...).

-- 
Ronald Fischer <ynnor@mm.st>

On Linux, the -p file test can tell you if STDOUT is connected to a pipe, no idea if that works on windows too (Update: -t is probably more informative than -p).

Why not simply pass the filename of the file-to-be-written to the program, and let it do the file writing in any case?

Because if I do this, I don't get any diagnostics about the error case. Note that I still *guess* what's going on, so for example the information "STDOUT in the error case is still connected to the same stream as in the parent" would be helpful.

On Linux, the -p file test can tell you if STDOUT is connected to a pipe, no idea if that works on windows too (Update: -t is probably more informative than -p).

There is an entry in perlfaq8 about this, which is not very encouraging:

How do I find out if I'm running interactively or not? Good question. Sometimes "-t STDIN" and "-t STDOUT" can give clues, sometimes not. if (-t STDIN && -t STDOUT) { print "Now what? "; }

-- 
Ronald Fischer <ynnor@mm.st>

Because if I do this, I don't get any diagnostics about the error case.

You could redirect the STDERR to STDOUT in the called perl program, then you wouldn't need to rely upon a broken bourne-shell emulation under windows.

system(1,['perl.exe','myProg.pl','>out.txt','2>&1'])

But perhaps this isn't the system we all know about. Perhaps it's a wrapper around something. Something that constructs the actual call to system. Now, the syntax suggest system is called with a list of arguments. Which means, no shell will be invoked. Which means, there's nothing out there that's actually going to interpret the > symbols. (And my bet is, myProg.pl ignores its arguments).

If the first argument to system is 1, it creates a process in the background. Unfortnately, this is not documented in system. See perlport for the details.
-- 
Ronald Fischer <ynnor@mm.st>

Indeed, so it does. I checked perlport before writing my post, but somehow, I manage to miss this. It does, however, say system(1, @args), not system(1, [@args]). And I assume it's equivalent to system(@args), which, as I said, results in calling perl.exe with three arguments: myProg.pl, >out.txt, and 2>&1. Try this instead: system(1, "perl.exe myProg.pl >out.txt 2>&1") or system("perl.exe myProg.pl >out.txt 2>&1 &")

$ perl -le "warn t => -t STDOUT"
t1 at -e line 1.

$ perl -le "warn t => -t STDOUT" >2
t at -e line 1.
[download]

-t is not exactly what the OP asked for, but it's probably what he wants.

$ perl -e"system 1, []"

$ 'ARRAY' is not recognized as an internal or external command,
operable program or batch file.
[download]

I think that's a windows-only feature. perlport might talk about it.
Perl 6 - links to (nearly) everything that is Perl 6.

I have windows, its not a windows feature, its made up syntax

Thanks - it was my typing mistake. I have corrected the code in my posting.
-- 
Ronald Fischer <ynnor@mm.st>