Thanks for your response.
I have got around the problem doing this (checked on Win32):
//first close the stderr opened by PERL
//open it again, and dup it...
int code = PerlIO_close(PerlIO_stderr());
if(code == 0)
{
PerlIO* newprlIO = PerlIO_open("prl.txt", "a+");
PerlLIO_dup2(fileno((FILE*) (newprlIO)),fileno((FILE*)PerlIO_stderr()));
}
int tmp = perl_parse(my_perl,xs_init,myargc,myargv,_environ);
...
...
PerlIO_close(newprlIO);
perl_destruct(my_perl);
perl_free(my_perl);
I am not sure how I could do this from my perl script. Could the first line
of the .pl or .pm file be closing stderr, opening another FD and redirecting
stderr to the new descriptor? But would this capture compilation errors?
Thanks again,
Gopa
-----Original Message-----
From: Nick Ing-Simmons [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 4:17 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: How to redirect STDERR under WIN32
Gopakumar Ambat <[EMAIL PROTECTED]> writes:
>>From the Perl source code, I gathered that "Perl_debug_log" is set to
>stderr; all calls to perl_printf etc.. are sent to Perl_debug_log.
>Tried #defining this to a new FILE* / PerlIO*
Which - they are NOT the same thing?
>- now the error info does not come
>out on the console but does not get re-directed to the file either...:(
>HELP!!!!!
Perl5.8 may not use stderr at all ;-)
In perl5.8 IO is done via PerlIO * things not FILE * things.
Now on some platforms hidden under a PerlIO * _may_ be a :stdio layer that
uses stdio to talk to stderr.
But on other platforms e.g. Win32 there is no connection between ANSI C's
stderr and perl's STDERR.
If you really want to redirect STDERR then it is much easier to do this from
perl code than C/C++ as the C entry point that handles standard streams is
PerlIO_openn() which has a very complicated interface to handle all the
possible ways perl can call it.
>
>Thanks,
>Gopa
>
>-----Original Message-----
>From: Gopakumar Ambat [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, July 27, 2004 6:19 PM
>To: 'muppet'
>Cc: [EMAIL PROTECTED]
>Subject: RE: How to redirect STDERR under WIN32
>
>I can't set stderr = fopen(..) since stderr cannot be an "l" value
>(it's #defined in the C lib stdio)..
Something odd there fopen() returns a FILE *
>What I can do is freopen(myfile,.., stderr), which theoretically
>redirects stderr to the file "myfile".
This is what you should do anyway as stderr is already open.
stderr = freopen(...,stderr);
It is possible (if unlikely) that FILE * returned will be a different one.
>This works fine
>on a simple C++ app, but not when perl.h is included... I guess perl.h
>over-rides the default behavior of stderr and I am unable to figure out
>what needs to be changed to over-ride Perl's interpretation!!!
With perl5.8+ your re-opening of stderr should work even with perl.h
included so that if you C++ code does fprintf(stderr,"...") it should go to
the new place.
Also if you really have (via the stdio library) close()d and re open()ed
numeric file descriptor 2, then perl's STDERR should also end up there.
>
>I had purposefully removed the semicolon so that the perl interpreter fails
>while parsing and returns an error!! :)
>
>Thanks,
>Gopa
>
>-----Original Message-----
>From: muppet [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, July 27, 2004 5:43 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: How to redirect STDERR under WIN32
>
>
>On Jul 27, 2004, at 6:09 AM, Gopakumar Ambat wrote:
>
>> ##########perl script:
>> ##########test.pl
>> use my_test.pm
>
>that should be either "use my_test;" or "require 'my_test.pm';".
>either way, it needs a semicolon, or you get the syntax error you saw.
>you also are responsible for making sure this file is available through the
>perl library search path.
>
>> print "inside test.pl script";
>
>don't forget that this probably won't show up until you print a newline to
>stdout.
>
>
>> My aim is to get the same error message while running the perl script
>> via the embedded C++ application. My understanding is that the error
>> message gets re-directed to "stderr", so I tried closing stderr and
>> reopening with a new file handle, but that doesn't seem to work; no
>> messages get routed to the "new" stderr!! Apparently the "stderr" has
>> been over-riden by the PERL IO layer, and I can't find a way to reset
>> that...
>
>did you do
>
> fclose (stderr);
> stderr = fopen (...);
>
>or
>
> close (2);
> dup (otherfd);
>
>?
>
>what i see is that PerlIO_stderr() calls PerlIO_stdstreams(), which, if
>it hasn't been called before, does PerlIO_fdopen(2, ...). so, in
>theory, if you redirect stderr's file descriptor before perl sees it,
>it ought to work.
>
>but, thanks to #ifdef magic, i don't know for sure that this code even
>gets called on win32, so you will want to take my comments with
>caution. does win32 even have dup()?
