abecher has asked for the wisdom of the Perl Monks concerning the following question:

On windows, STDOUT comes up missing in this example. Can anyone explain what is happening?
Here's the example: (I more'd this from unix - the scripts run as-is under windows or unix) 
-> more bug*
::::::::::::::
bugSTDOUT.pl
::::::::::::::
#!/usr/bin/perl
print STDOUT "Running bugSTDOUTb.pl with backticks\n";
print STDOUT "stdout from bugSTDOUTb.pl=" . `bugSTDOUTb.pl` . "\n";
::::::::::::::
bugSTDOUTb.pl
::::::::::::::
#!/usr/bin/perl
print STDOUT "Running bugSTDOUTc.pl with system()\n";
system('bugSTDOUTc.pl');
print STDOUT "$0 done\n";
::::::::::::::
bugSTDOUTc.pl
::::::::::::::
#!/usr/bin/perl
print STDOUT "Hello world!\n";

[download]
On unix, the output is as expected: 
->  bugSTDOUT.pl
Running bugSTDOUTb.pl with backticks
stdout from bugSTDOUTb.pl=Running bugSTDOUTc.pl with system()
Hello world!
/u/geaaron/bin/bugSTDOUTb.pl done

[download]
But on windows, the STDOUT from the 3rd script is missing: 
D:\My\Tools>bugSTDOUT.pl
Running bugSTDOUTb.pl with backticks
stdout from bugSTDOUTb.pl=Running bugSTDOUTc.pl with system()
D:\My\Tools\bugSTDOUTb.pl done

[download]
Where did the STDOUT go? Is there a solution to this problem? I really need windows to do the same thing unix does...

NOTE: This does not happen for STDERR. If you s/STDOUT/STDERR/g things work as expected on both platforms.

Thanks, Aaron

Replies are listed 'Best First'.
Re: STDOUT missing on Windows, works on Unix
by ikegami (Patriarch) on Dec 13, 2008 at 07:25 UTC

    Windows handling of non-binary executables is buggy. It used to be you couldn't redirect the output of batch files at all. ("command /c batch > file" was required.) Change "script.pl" to "perlscript.pl" and it works.

[reply]
[d/l]
[select]
      This is exactly the info I was looking for!! The IO re-direction has plagued us for a long time since we've moved a lot of our unix tools to Windows. It's one of those issues that popped up every once in a while and we never understood why or how to fix it. I passed along the info that, when we're running a perl script that wants to capture the STDOUT of another perl script, to not just use: 
      my $stdout = `otherscript.pl`;

      [download]
      but instead to use: 
      my $stdout = `$^X otherscript.pl`;

      [download]
      Thank you very much!
      Aaron
[reply]
[d/l]
[select]
        Hmmm, 'unix tools to Windows' - odd move - I wonder if you'll be moving back once XP goes EOL & you tire of waiting for vista ... to do anything!

        Just a thought

        A user level that continues to overstate my experience :-))
[reply]
Re: STDOUT missing on windows
by jwkrahn (Abbot) on Dec 13, 2008 at 07:17 UTC
[reply]
      Thanks for the tip. I did read through the recommended article, but it didn't help me. It WAS a good refresher on some other important stuff though! I believe I was even getting hit by the cgi issue mentioned not too long ago and spent some time beating my head on the wall :-)
      Aaron
[reply]
      Given that STDERR works, I thought it might be that at first too. But that's not the problem. Turning off buffering doesn't help.
[reply]

        I'm glad I don't use Windows.    ;-)

[reply]
[d/l]
Re: STDOUT missing on Windows, works on Unix
by BrowserUk (Patriarch) on Dec 13, 2008 at 09:11 UTC
    I really need windows to do the same thing unix does...

    Hm.

    1. Does /usr/bin/perl exist on your windows system(s)?
    2. Have you installed something on those windows systems that attempts to determine which executable should be used to process a data file by inspecting the first line of that file?

    If your answer is no to either, it is your expectations that are buggy, not the systems you are using.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      Are you implying the script isn't getting run? I can recreate the problem, and I've verified that it is getting run (by checking its exit code and having it touch a file) despite it's output going missing.
[reply]
        Are you implying the script isn't getting run?

        No! I'm stating that how it gets run is of prime importance to the cause of the problem and its solution.

        And that if you rely upon the windows "equivalent" of the unix shebang mechanism, it is enacted by the system shell, rather than by one of the system APIs. And that cannot be attributed to a 'bug' in windows, but simply a difference in the way the two platforms are designed to work.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        I knew the script was getting run. My example was just as small a testcase as possible to illustrate what was happening. Adding the "$^X" inside the backticks solved the problem as you said. Of course, that's just the easy fix to running another perl script, but that's about all we do unless we're running an actual .exe of some kind (which falls into you're "binary so ok" category).
        Thanks again!
        Aaron
[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom