in reply to capturing command output

Considering all you do is run a command, and collect its output and errors, and return a string with said output and errors, I see no advantage of not using backticks. The backticks will also use the shell, but that doesn't really matter. Your fetch_cmd basically is a reimplementation of backticks.

Replies are listed 'Best First'.
Re^2: capturing command output
by chrestomanci (Priest) on Jan 25, 2012 at 13:52 UTC

    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.

[reply]
[d/l]
      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]
Re^2: capturing command output
by pklausner (Scribe) on Jan 25, 2012 at 14:32 UTC
    > Your fetch_cmd basically is a reimplementation of backticks.
    Yes. But besides handling stderr it gives you another layer of indirection. And as the saying goes: there is not problem you cannot address with another layer of indirection ;-) Here it might actually be useful for logging the call (if it's generated) or storing the output for later inspection (it may not look as expected) or discard stderr or...
[reply]
      But besides handling stderr it gives you another layer of indirection.
      So what? You have any idea how many layers of indirection there are on the open call? Or on the reading? Why is the number of layers of redirection an argument against backticks, but not about open, or the diamond operator?
      Here it might actually be useful for logging the call (if it's generated) or storing the output for later inspection (it may not look as expected) or discard stderr or...
      Sure, but he isn't doing any of that. One can critic any piece of code with "yeah, but if you want to do X in the future, it becomes harder". With arguments like that, you'd never write down a single line of code.
[reply]
        Why is the number of layers of redirection an argument against backticks

        Sorry, must be a misunderstanding. Of course backticks operator and open call are equivalent. I meant to say that the extra subroutine adds a layer. And unless the external command is trivial or absolutely, totally predictable, this comes in handy to instrument it. At least that is my experience. That's why I normally code a wrapper around system calls. More than one way etc...

[reply]

In Section Seekers of Perl Wisdom