Re: debuggers
"Dave" == Dave Rolsky [EMAIL PROTECTED] writes:
Dave On Thu, 7 Dec 2000, martin langhoff wrote:
I wonder how do those hardcore guys that develop using handlers
debug. Mhhh. They must write 'perlfect' code, I guess, and/or
understand those cryptic debuggers ...
Dave I just do a lot of debugging via warn statements and looking
Dave at the error logs.
My BEGIN block looks like this. I realize IO is rather bulky, but I
like it and the environment I'm in isn't *that* busy where it makes a
significant impact.
BEGIN {
# Wash the PATH.
$ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
$ENV{'CDPATH'} = '';
$ENV{'ENV'} = '';
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
use Savvy::Conf qw(:WWWBasic);
my $log = 1;
my $logfile = "/www/cgi-logs/cgi-log";
if ($log) {
my $LOG = IO::File-new(" $logfile") or
Savvy::Conf::cab("Unable to open $logfile for writing: $!\n");
# Dupe STDERR. Original is SAVEERR.
carpout($LOG);
}
}
Then I 'tail -f' the $logfile, the Apache server error_log, and watch
watever comes to the broswer due to the fatalsToBrowser. Works well for
me.
The '$r-log_reason' finds a home in my code as well.
Plus, I *always* use '-w' and '-T' and get them cleanly working during
development phases, although I shut them off for actual deployment.
Peace.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
"Dave" == Dave Rolsky [EMAIL PROTECTED] writes:
Dave On Thu, 7 Dec 2000, martin langhoff wrote:
I wonder how do those hardcore guys that develop using handlers
debug. Mhhh. They must write 'perlfect' code, I guess, and/or
understand those cryptic debuggers ...
Dave I just do a lot of debugging via warn statements and looking
Dave at the error logs.
My BEGIN block looks like this. I realize IO is rather bulky, but I
like it and the environment I'm in isn't *that* busy where it makes a
significant impact.
BEGIN {
# Wash the PATH.
$ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
$ENV{'CDPATH'} = '';
$ENV{'ENV'} = '';
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
^^^
Bye bye exception handling.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
Plus, I *always* use '-w' and '-T' and get them cleanly working during development phases, although I shut them off for actual deployment. 1. You cannot use -T under mod_perl, you should use PerlTaintCheck instead: http://perl.apache.org/guide/porting.html#Taint_Mode 2. 'PerlTaintCheck On' is a must in production!!! not development: * http://www.gunther.web66.com/FAQS/taintmode.html * perldoc perlsec _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
"SB" == Stas Bekman [EMAIL PROTECTED] writes: SB 2. 'PerlTaintCheck On' is a must in production!!! not development: Huh?!?!?!? It is a must always. You can't develop without it and then expect it to work with taint checking on at a later time. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes:
Matt On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
Thanks! Maybe I'll learn something here, which is why I posted it in
the first place.
http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Plus, I *always* use '-w' and '-T' and get them cleanly working during development phases, although I shut them off for actual deployment. Stas 1. You cannot use -T under mod_perl, you should use StasPerlTaintCheck Stas instead: http://perl.apache.org/guide/porting.html#Taint_Mode This is what I was referring to actually. However, there are many modules, such as Date::Manip, for example, that just will not load with taint checking turned on. In an intranet, it's not as big a deal as it certainly is in the 'real world'. But what can I do, short of rewritting the parts of the module that don't function in with checking on Stas 2. 'PerlTaintCheck On' is a must in production!!! not Stasdevelopment: Stas * http://www.gunther.web66.com/FAQS/taintmode.html Stas * perldoc perlsec Thanks for the input. Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes:
Matt On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
properly using eval{} blocks, or nice modules like Error.pm or
Class::Exception (or whichever way around Dave has it this week :-)
See my rant, erm, section in the guide on exception handling.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
"Stas" == Stas Bekman [EMAIL PROTECTED] writes:
Plus, I *always* use '-w' and '-T' and get them cleanly working
during development phases, although I shut them off for actual
deployment.
Stas 1. You cannot use -T under mod_perl, you should use
StasPerlTaintCheck
Stas instead: http://perl.apache.org/guide/porting.html#Taint_Mode
This is what I was referring to actually. However, there are many
modules, such as Date::Manip, for example, that just will not load with
taint checking turned on. In an intranet, it's not as big a deal as it
certainly is in the 'real world'.
You should contact the author of the module and ask him to fix it. It's
possible that he doesn't aware of the taint issues. Usually for modules
that execute shell/fork but don't pass any tainted args, the fix is as
trivial as adding:
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
(taken from perlsec manpage)
Hmm, may be we should find a way for modules to be taint checked before
these are allowed to CPAN? What do you think? sort of:
eval {`perl -cwT $_` for (*.pm) };
But what can I do, short of rewritting the parts of the module that
don't function in with checking on
Stas 2. 'PerlTaintCheck On' is a must in production!!! not
Stasdevelopment:
Stas * http://www.gunther.web66.com/FAQS/taintmode.html
Stas * perldoc perlsec
Thanks for the input.
You are very welcome :)
Peace.
Sex, drugs and rock-n-roll!
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes:
Matt On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
Thanks! Maybe I'll learn something here, which is why I posted it in
the first place.
Peace.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Fri, 8 Dec 2000, Matt Sergeant wrote:
fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
properly using eval{} blocks, or nice modules like Error.pm or
Class::Exception (or whichever way around Dave has it this week :-)
That's Exception::Class. phhhbbtt!
-dave
/*==
www.urth.org
We await the New Sun
==*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
Perrin, In fact, I've always been coding from NT machines -- for my *nix servers, of course. Now the ActiveState people are building a cross-platform and cross-language IDE that integrates with perldebug nicely -- or so it seems. I'm actually starting to like it -- it's built on top of mozilla, so its a bit bloated and slow -- but I like it, just like mozilla ;) And, on top of that, it's called Komodo, and that means 'comfort' -- in Spanish, that is. All this talk about DDD is making me wonder if there is a suitable (graphical) Perl IDE that I can run on Gnome. If there's one, maybe I'll change my dev workstation from an NT box to RHLinux 6.1 ... Well, there's Komodo, for instance ;) martin pd: of course, in Spanish you'd say cómodo -- with a stress on the first o. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Thu, 7 Dec 2000, martin langhoff wrote: All this talk about DDD is making me wonder if there is a suitable (graphical) Perl IDE that I can run on Gnome. Last time I tried them, I found ptkdb a bit nicer than DDD, mostly because DDD was kind of slow. I don't know how easy it is to make it play with mod_perl though. Apache::Debug normally just dumps you into the shell debugger. Maybe setting an environment variable would do it. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
Perrin Harkins wrote: I don't know how easy it is to make it play with mod_perl though. Apache::Debug normally just dumps you into the shell debugger. Maybe setting an environment variable would do it. I've always considered mod_perl to be completely debugger-unfriendly. That's why I write modules that I can test from a standard script, and then call those modules from Embperl pages or Registry scripts. I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Thu, 7 Dec 2000, martin langhoff wrote: I've always considered mod_perl to be completely debugger-unfriendly. That's why I write modules that I can test from a standard script, and then call those modules from Embperl pages or Registry scripts. Apache::Debug works. It's almost exactly the same as debugging a standard script. I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... Do not be afraid of the command line... The Perl debugging shell is really not so hard if you give it a chance. I've taught a number of people here how to use it. I'm always amazed that more people don't use tools like the debugger and the profiler. They're life savers. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Thu, 7 Dec 2000, martin langhoff wrote: Perrin Harkins wrote: I don't know how easy it is to make it play with mod_perl though. Apache::Debug normally just dumps you into the shell debugger. Maybe setting an environment variable would do it. I've always considered mod_perl to be completely debugger-unfriendly. That's why I write modules that I can test from a standard script, and then call those modules from Embperl pages or Registry scripts. I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... Personally I've always relied on sending debug messages to the log, and then staring at the code for a few minutes/months. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
On Thu, 7 Dec 2000, martin langhoff wrote: I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... I just do a lot of debugging via warn statements and looking at the error logs. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
martin langhoff wrote: I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... Actually, debugging handlers is pretty easy. Just run httpd with the -X flag to make it single process, and use Apache::DB to get mod_perl to run under the debugger. Get Apache::DB from CPAN perl -MCPAN -e 'install Apache::DB' and read its docs perldoc Apache::DB When Apache hits your Perl code, you are dropped into the standard Perl debugger. Although typing '?' at the debug prompt shows a bewildering array of options, you can do a lot by knowing: n - Step over s - Step into x expr - Print the value of expr w - Show a few lines either side of the current one b sub - break at sub c - continue (stop debugging) c line# - continue, and break at line# HTH, Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
Perrin Harkins wrote: On Thu, 7 Dec 2000, martin langhoff wrote: I've always considered mod_perl to be completely debugger-unfriendly. That's why I write modules that I can test from a standard script, and then call those modules from Embperl pages or Registry scripts. Apache::Debug works. It's almost exactly the same as debugging a standard script. i got it running once on our dev box and then no go ever since then but yes it is sweet! I wonder how do those hardcore guys that develop using handlers debug. Mhhh. They must write 'perlfect' code, I guess, and/or understand those cryptic debuggers ... Do not be afraid of the command line... The Perl debugging shell is really not so hard if you give it a chance. I've taught a number of people here how to use it. I'm always amazed that more people don't use tools like the debugger and the profiler. They're life savers. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
