in reply to capturing stderr of a command, invoked via backticks

Good question. You need to remember that "redirecting" output (including stderr) to a variable is magic which happens only within the current perl process. It's saying "redirect my stderr to a variable". This does not propagate into subprocesses. (Wouldn't that be nice.) But the current process's real stderr has been turned off, and this fact does propagate into subprocesses.

As perlop says,

To read both a command's STDOUT and its STDERR separately, it's easiest to redirect them separately to files, and then read from those files when the program is done.

Of course, you could also try using IPC::Open3.

A word spoken in Mind will reach its own level, in the objective world, by its own weight
  • Comment on Re: capturing stderr of a command, invoked via backticks

Replies are listed 'Best First'.
Re^2: capturing stderr of a command, invoked via backticks (pipeS)
by tye (Sage) on Sep 08, 2007 at 05:25 UTC
    As perlop says,
    To read both a command's STDOUT and its STDERR separately, it's easiest to redirect them separately to files, and then read from those files when the program is done.
    Of course, you could also try using IPC::Open3.

    But beware that trying to read both STDOUT and STDERR separately using Perl and IPC::Open3 can be a good way to discover what "deadlock" means. You'd need to use something like select (select doesn't work on pipes on Win32 and the equivalent that does work isn't packaged up for easy use from Perl) or have two threads of execution, so coding this correctly may be much more complicated than using a temporary file or two.

    - tye