Re^2: STDERR going to string

[philkime]

in reply to Re: STDERR going to string
in thread STDERR going to string

I can get around this by redirecting to a file and reading it later. I suspect I could use Config::Tiny or File::Tee too but it seems it's a harder problem on Windows because re-opening STDERR decouples perl's STDERR from the called C library's STDERR which seems impossible to capture. If anyone has any ideas about this ... Since the issue is a library called from XS and not the XS extension itself and the fact that this library is also used apart from perl, it can't be modified to use PerlIO ...

[Anonymous Monk]

If you want to capture STDIN/STDOUT/STDERR, you have to launch another process, see IPC::Run3, IPC::System::Simple

[philkime]

It's not really the output of an external command etc. I need. It's the STDERR of a C library which an XS module uses. So when I make certain sub calls, it gets into the C routines and it's their STDERR I want to capture. It all works fine on non-Windows using STDERR redirection to a file or Capture::Tiny but on Windows, the STDERR of the library refuses to be captured. This seems to be a windows specific thing - I read somewhere that re-opening STDERR on windows de-couples perl STDERR from the C library STDERR. If so, I'm really in the dark as to how to capture this.

[Anonymous Monk]

...repetitive...I'm really in the dark as to how to capture this.

Like I already said, launch a process

perl foo.pl 1>my.stdout.txt 2>my.stderr.txt always works

[Anonymous Monk]

because re-opening STDERR decouples perl's STDERR from the called C library's STDERR

It will probably work if you save/dup STDERR and restore it

open my $errsave, '>&', STDERR
  or do { print "couldn't dup STDERR: $!"; exit 2; };
open STDERR ...
...
open STDERR, '>&', $errsave
  or do { print "couldn't restore/dup STDERR: $!"; exit 2; };