Just thought I'd share with the group and experience I just had. In perhaps
the hope of sparing others of the PITA I just went through.
First of all, I will acknowledge I am perhaps not the best of programmers...
Perhaps being an understatement.
Second of all, it is not a request for a "better way to code" this. This is a
recounting of some troubleshooting I just endured due to a programmer very much
more clever than I.
First, allow me to present the offender(s):
sub timestamp {
return strftime( "%Y-%m-%d %H:%M:%S", gmtime($_[0] || time()) );
}
my $ts0 = UnixDate( Date_ConvTZ( ParseDate( timestamp() ),"GMT",$tz),"%Y-%m-%d
%T" );
The original environment for this code is a Linux system running Perl 5.8.8 and
it performed flawlessly there and was successfully transplanted to 5.10.0 with
no changes needed.
When the application containing the code above was transplanted to a system
running Perl 5.12.3... Well, lets just say this is where the fun began.
When it comes to Perl installations, I long ago learned not to trust
Distribution provided modules so I always use CPAN to install from. Basic
Perl, from the Distro, sure... Add
on modules, not so much. Often the modules I want aren't even in the distro
and for module sets I use often I have little shell scripts to load the
necessary modules from CPAN. I
don't really look at it that much. Maybe not the best practice, but I'm busy.
I also want to say, this is code a wrote a couple of years ago. I've not
touched it since and have
since moved on to other things.
When the report came in that important function weren't working I first had to
find the location of the failing code. Is it being passed it's necessary data.
Yep... OK, so what's
wrong? Any errors thrown? Nope. OK, extract the code into a test program
(below, suitably "cleaned" to disguise what it really is). "In circuit" the
code runs as a daemon and
errors aren't easy to get at.
#!/usr/bin/perl -w
use lib '../lib';
use Common; # contains timestamp()
use Date::Manip;
my $graphdates='';
$graphdates .= "&action=plot&ts2=" . UnixDate( Date_ConvTZ( ParseDate(
timestamp() ),"GMT",$tz),"%Y-%m-%d %T" );
$graphdates .= "&ts=" . UnixDate( Date_ConvTZ(DateCalc( ParseDate(
timestamp() ), "- 120 Minutes" ),"GMT",$tz),"%Y-%m-%d %T" );
my $test = UnixDate( Date_ConvTZ( ParseDate( timestamp()
),"GMT",$tz),"%Y-%m-%d %T" );
print STDERR "$test\n"
In the test program, the conversion stream works correctly. OK... Now what?
Maybe the module didn't install correctly?! Hand install with UNINST=1 set
The application still misbehaves but now I have the all distribution files so I
dig into the docs where I find this:
FUNCTIONAL INTERFACE (VERSION 5)
When using a version of perl older than 5.10, this is the only interface
available. This interface is documented in the Date::Manip::DM5
document.
(The above should read 5.10 and below, because the code worked exactly as it
did under 5.8.8 at 5.10.0)
and this:
DATE_MANIP ENVIRONMENT VARIABLE
By setting the DATE_MANIP environment variable to 'DM5' before
running the perl script, the version 5 interface will be used.
suffice to say, problem solved!
insert
export DATE_MANIP=DM5
into the daemon startup script and enable mod_env in the apache that runs other
parts, adding
SetEnv DATE_MANIP DM5
to the apache config file.
Now here comes my question:
Shouldn't this have thrown SOME kind of error/warning what was going on? Is
silent failure a proper behavior no matter how clever the switch around is?
Just asking.
Respectfully,
Bruce Ferrell
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
