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

> 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...

Replies are listed 'Best First'.
Re^3: capturing command output
by JavaFan (Canon) on Jan 25, 2012 at 15:59 UTC
    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]
        That's why I normally code a wrapper around system calls.
        Like this? 
        sub backticks {
    `$_[0]`;
}

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom