> -----Original Message-----
> From: WC Jones [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 March 2004 11:55 AM
> To: David le Blanc
> Subject: Re: Enable Perl Debugging at Run-Time
>
> On Wed, Mar 10, 2004 at 11:15:39AM +1100, David le Blanc wrote:
> >
> > While inside a CGI script? enlighten me!
>
> lol :)
>
> You sure you want to be seen talking to me? I resigned from
> the Perl lists because not being a programmer I dont see
> things the way programmers do.
Can be a good thing. You probably get on better with the opposite sex
:_)
> Does this not work out:
>
> open(STDOUT,"> file") || die "Can't redirect STDOUT to file: $!\n";
> open(STDERR,"> file") || die "Can't redirect STDERR to file: $!\n";
>
> At any rate, I cannot see your orginal post (not at my home
> where my server is and the post doesnt seem to have made it to
> the mail / Usenet archives yet.) I was under the impression
> that you were debugging a program PRIOR to making it a CGI -
> which is how I do things -- but I am weird.
>
> If yoyu want to capture the output there are TONs of Apache
> modules for this.
I do all of the above. The script has left its infancy and it now a CGI
with kookies, and forms and other stuff, each of which can be
individually
emulated however tripping the problem I was diagnosing required a
process
'flow', ie, I had to clear the state tables in the database and perform
a
sequence of operations all of which re-entered the CGI with accumulating
state information, user authentication data and cookie crumbs.
Redirecting STDOUT is bad since I want print to go to the web client
I redirect STDERR to capture warnings (-w) and compilation errors to a
log
file. I open a 'debug' log, and 'print DEBUG' to it for application
logging,
and I intersperse the debug log with spats of code-traces enabled around
the
suspicious code at run time. (via my perl -d and DB::DB(){tweaks}) I
also
trap $SIG{__DIE__} to make sure I capture what I can about fatals and
log
them to my trace file.
I even went so far as to have a table in the database, which the perl
code
looks up to decide which modules/functions to trace (table loaded into a
HASH when
the program first runs) hence I don't need to edit the program to turn
debug handling on and off again.... I can add a function to the 'trace
list'
without breaking my stride while using the web page(s).
Oh, and to top it all off, it uses speedy_cgi, which means global
variables
and state information works differently than you might expect !!!
It all works fine. I guess I was hoping someone could suggest an
alternative
to '-d' which would enable me you turn perls *slowish* internal
debugging engine
on and off at run-time. It doesn't really make sense if you think about
it
though... sigh..
Ie, -w is the same as '$^W=1' or 'use warnings' <-- exists
-d is the same as '$^d=1' or 'use debug qw( <debug_module> );' <--
hypothetical
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
