From perlport I concluded that system(1,...) would do the redirection, provided that the application does not run on RISC OS (because for the latter, the doc explicitly mentions that redirection is NOT performed).
Maybe I read too much into this docs, because for Win32, the redirection problem is not mentioned at all. Since the docs said with RISC OS that redirection does not work, I concluded that on those operating systems where the documentation does not mention redirection, it should work, but actually not mentioning it just means "undefined behaviour". Hence I admit that we can not rely on redirection performed automagically in this case. Of course the question is why it had worked often. I think the answer lies in the following sentence from perlport: system ... As an optimization, may not call the command shell specified in $ENV{PERL5SHELL}.. So I guess that (maybe depending on the arguments), sometimes CMD.EXE was called, and redirection performed; but sometimes the sub-process was started immediately, without CMD.EXE, and no redirection was performed.
However even this explanation doesn't satisfy completely: If indeed no redirection is performed by Perl, the called process should see the arguments ">...", "2>&1" in @ARGV, but they are not present. Something is eating them without doing proper redirection...In reply to Re^6: Test whether STDOUT is connected to a file
by rovf
in thread Test whether STDOUT is connected to a file
by rovf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |