Re: Debugging PAR packaged programs

The config file is pretty simple:

activation code= 4960256a
directory = C:\\Documents and settings\\DrewB\\Local Settings\\Applica
+tion Data\\Windows NT\\NTBackup\\data
file=*.log
date in file = 720
file age = 720
date pattern=Backup completed on (?<month>\d+)\/(?<day>\d+)\/(?<year>\
+d+).+?(?<hour>\d+):(?<minute>\d+)\s*(?<mark>AM|PM)
[download]

I'm not actually getting any perl errors. However, when it gets to the following line:

my $cmdLine = "java -cp $CPATH com.nable.server.edf.GenericApp.EDFGenericApp $activationCode EDF_SERVICEID_1050000:$dateFail EDF_SERVICEID_1050001:$failures EDF_SERVICEID_1050002:$fileFailCount EDF_SERVICEID_1050003:$warnings";

The $activationCode is empty. I placed several print "$activationCode\n" lines in different places in the code and from what I can tell, it's never getting read out of the file as the one in the original code I posted never even fires.

Comment on Re: Debugging PAR packaged programs Select or Download Code

Replies are listed 'Best First'.
Re^2: Debugging PAR packaged programs by wanna_code_perl (Friar) on Dec 09, 2008 at 17:34 UTC
Nothing immediately obvious comes to mind. In cases like this, often the simplest solution is to instrument the code with some simple debug statements. `while(<CONFIG_FILE>) { print("Line: $_\n"); if(/^backup path\s=/) { (undef, $backupPath) = split(/\s=\s/,$_); } elsif(/^activation code\s=/) { (undef, $activationCode) = split(/\s=\s/,$_); print "activation code: $activationCode\n"; } # etc...` [download] If you see the "activation code=" line, but your following `$activationCode` print doesn't show, then you know you have a parsing problem. If you never see the "activation code=" line at all, perhaps you're somehow missing reading the first line of the file. Anyway, even in the absence of external modules, this ugly code could have been made cleaner and less error prone with something like this: my %config; foreach (<CONFIG_FILE>) { unless (/^\s(.+?)\s=\s(.+?)\s$/) { chomp($_); warn "Invalid config format: `$_'"; next; } $config{$1} = $2; } [download] This way, you don't pollute your global namespace with configuration variables, and you now have a 1:1 mapping between configuration variable names and hash keys, which has got to be easier to remember and maintain. You should still definitely have additional error checking and some validation checks after the file is read.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Debugging PAR packaged programs
by wanna_code_perl (Friar) on Dec 09, 2008 at 17:34 UTC

    while(<CONFIG_FILE>) {
        print("Line: $_\n");
        if(/^backup path\s*=/) {
            (undef, $backupPath) = split(/\s*=\s*/,$_);
        } elsif(/^activation code\s*=/) {
            (undef, $activationCode) = split(/\s*=\s*/,$_);
            print "activation code:  $activationCode\n";
        } # etc...
[download]

If you see the "activation code=" line, but your following $activationCode print doesn't show, then you know you have a parsing problem. If you never see the "activation code=" line at all, perhaps you're somehow missing reading the first line of the file.

Anyway, even in the absence of external modules, this ugly code could have been made cleaner and less error prone with something like this:

my %config;

foreach (<CONFIG_FILE>) {
    unless (/^\s*(.+?)\s*=\s*(.+?)\s*$/) {
        chomp($_);
        warn "Invalid config format: `$_'";
        next;
    }
    $config{$1} = $2;
}
[download]

This way, you don't pollute your global namespace with configuration variables, and you now have a 1:1 mapping between configuration variable names and hash keys, which has got to be easier to remember and maintain.

You should still definitely have additional error checking and some validation checks after the file is read.

[reply]
[d/l]
[select]