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

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

Replies are listed 'Best First'.
Re^6: STDERR going to string
by philkime (Beadle) on Oct 11, 2011 at 09:49 UTC
    I don't think I understand how to do that in my case. I am in the middle of a large program and need to make some sub calls to some XS/external lib subs. There isn't anything I can really launch as an external processs here. Am I missing something? I know it'll always work if I redirect everything before I start but my problem is that I am already deep in some code at the point where I need to run some XS subs and get their STDERR.
[reply]

      Am I missing something? 

      $ perl -le " print for map { fileno $_ }  \*STDIN, \*STDOUT, \*STDERR 
+"
0
1
2

      [download]

      There is nothing you can do to change the fileno of STDIN/STDOUT/STDERR on a c-level on win32, they're always 0 1 2, so any c code printing on STDERR is printing on 2, always

      To capture STDERR you have to launch a process, or

      Patch XS module to use perl functions for printing to stderr (perlclib), so that when you redirect STDERR/STDOUT (like using IO::NestedCapture), it notices

[reply]
[d/l]
        Ok, thanks. I looked into patching but the STDERR stuff comes from a library which the XS uses, not the XS itself. To perlIO that would probably be too tricky (for me, anyway). I wonder if I could get round it with a simple fork() around the sub calls ...
[reply]

In Section Seekers of Perl Wisdom