God that is offensive code! No wonder you are having problems. Have you considered a module to manage your config files. cpan:Config::Auto is something that comes to mind.

Basically, if you are going to do something like this(ie: something that has been done already). Try and find a module that does it for you and maybe you can avoid these sorts of issues.

This is not always possible in certain environments, Herkum, due to the local political climate. Knowing how to write something correctly given the tools available is legitimate, even if a module out there does it cleaner. The other thing about modules is the lack of maintenance and occasional setup errors that turn folks off to the whole experience.

Absolutely true, and mind-numbingly aggravating. I hear "only use core" all the time, or maybe "only use what you can find via yum in the official repositories for this antiquated CentOS version we're using." It's like telling me to only run my car only with what was in it when I bought it, or maybe using the resources available at the dinky little gas station around the corner from my apartment.

It takes little research to discover what modules are available and actively maintained. Unfortunately, that's not enough to satisfy a corporate policy that fears the outside world. Pardon me, I need to go find a brick wall to smash my head against for a few minutes.

Oh, that original could would be at least a little cleaner if it just split each line into a key/value pair and stored the results in a config hash. It wouldn't necessarily solve the problem of the missing value, but it would be easier to debug by reducing lines of code.

Now about that brick wall ...

It may not always be possible but that is not the case here. It is bad code, and the programmer needs to fix it. The easiest way for them would be for them to use a module. It would solve two issues, it makes them more flexible to new solutions, and there is a good chance that it will work better than anything that is home grown.

It is easy to say its corporate politics that prevents me from doing 'blah' and continue doing what you are doing.

I find that it leads to people who think they know more than they do, writing more code than they should and introducing bugs because of things they have not thought of before... And more than likely, they just did not ask!

Yes, even you can use CPAN

---

Perl's payment curve coincides with its learning curve.

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:

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.

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.