Re: STDERR going to string

Your basic problem is that T::BT uses XS code which in turn uses stdio instead of perl IO to print to stderr. Capturing this will become much more problematic, though not necessarily impossible.

There may be modules that can handle this, I'm not sure. However, one for-sure way to do this is to call T::BT in a subprocess, and capture its stderr. Inside a single process, you may be able to set up threads (even Coro threads) or events with a pipe - set up your stderr to a pipe (which is handled by the C library just fine) and have an event listener/thread read it in and append it to your string manually.

I don't think perl can do this by itself with the reference-to-a-scalar trick.

Long term, ask the module author to use perl IO instead of stdio for their output in XS code.

Comment on Re: STDERR going to string

Replies are listed 'Best First'.
Re^2: STDERR going to string by philkime (Beadle) on Oct 03, 2011 at 19:12 UTC
Ah, I see, thank you. I assumed it was something to do with how the library/module handled STDERR ... I'll see what I can do.	[reply]
Re^2: STDERR going to string by philkime (Beadle) on Oct 10, 2011 at 13:23 UTC
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 ...	[reply]
Re^3: STDERR going to string by Anonymous Monk on Oct 10, 2011 at 13:38 UTC
If you want to capture STDIN/STDOUT/STDERR, you have to launch another process, see IPC::Run3, IPC::System::Simple	[reply]
Re^4: STDERR going to string by philkime (Beadle) on Oct 11, 2011 at 08:21 UTC
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.	[reply]
Re^5: STDERR going to string by Anonymous Monk on Oct 11, 2011 at 09:06 UTC
Re^6: STDERR going to string by philkime (Beadle) on Oct 11, 2011 at 09:49 UTC
Some notes below your chosen depth have not been shown here
Re^3: STDERR going to string by Anonymous Monk on Oct 12, 2011 at 10:13 UTC
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; };` [download]	[reply] [d/l]