http://www.perlmonks.org?node_id=949908


in reply to Re: capturing command output
in thread capturing command output

The OP's script captures both STDOUT and STDERR, but plain backticks will only capture STDOUT.

As a demo, I used a script like this:

#!/usr/bin/perl
print STDOUT "hello\n";
print STDERR "world\n";

[download]

If you run it on a bash cmd line you get both lines of output as you would expect. If you call via perl backticks then only "hello" is captured, and "world" is still sent to stdout.

Replies are listed 'Best First'.
Re^3: capturing command output
by JavaFan (Canon) on Jan 25, 2012 at 15:54 UTC
    If you call via perl backticks then only "hello" is captured, and "world" is still sent to stdout.
    I cannot reproduce that. 
    $ cat foo
#!/usr/bin/perl
print STDOUT "hello\n";
print STDERR "world\n";
$ cat bar
#!/usr/bin/perl
use 5.010;
my $output = `./foo 2>&1`;
say "[[$output]]";
$ chmod +x foo
$ chmod +x bar
$ ./bar
[[world
hello
]]
$

    [download]
    Or are you suggesting the OP would run a different command in backticks than in his open? Why would he do that?
[reply]
[d/l]
      Or are you suggesting the OP would run a different command in backticks than in his open? Why would he do that?

      No I am saying that plain backticks, without the 2>&1 shell redirection only captures stdout. If you add the shell redirection then of course you get stderr as well, because you asked the shell to do that for you. (Though as Eliya has demonstrated, it is actually perl intercepting the redirection shell trick and doing it within perl.)

[reply]
[d/l]
        Hmmm, so, you're saying, it's wrong to use backticks, because if you only put half the command in the backticks, it doesn't work?

        I think that's one of the more stupid arguments one can make. If the OP would remove the 2>&1 from his original solution, it would break in the same way.

[reply]
[d/l]

In Section Seekers of Perl Wisdom