What strict and Karl were pointing out is that you need to tell perl the scope of $APPSUPPORT_PATH ¹. By default, strict perl wants you to be explicit on all variables, so if you wanted the variable to be global to your main package (the default package in a perl program), you should refer to the variable as $main::APPSUPPORT_PATH -- hence, the message "requires explicit package name". If you want to leave it in the global main package, but refer to it more shortly, you would declare it as our $APPSUPPORT_PATH = ... -- but this still fills up the main namespace, which you probably don't need to do, since you aren't referring to the variables from any lexical scope other than this file. Instead, you probably want to limit that variable's scope to the current lexical block (in your circumstance, the file-level scope), which would be done with my $APPSUPPORT_PATH = ....

See perldoc my and our for the details of those two functions. And see Coping with Scoping for more on the scope of variables.

update: ¹$APPSUPPORT_PATH, and all those other variables in your list of variable definitions.

"...every line is wrong..."

A programmer's fate.

This is the way i do it to avoid unnecessary trouble:

#!/usr/bin/env perl

use strict;
use warnings;

...;

__END__
[download]

Years ago i did it like this because i thought that it is more "readable":

#!/usr/bin/env perl

use strict;
use warnings;

MAIN: {

    ...;

}

sub foo { ...; }

sub bar { ...; }


__END__
[download]

It is not a bad idea to add a POD section after the __END__ token. See How can i debug compound map/grep statements just using print? for an example.

Please see also my, our, local, strict, warnings (already mentioned by others), diagnostics and perlpod.

And for a more detailed look "under the hood" see B::Deparse, B::Terse, B::Concise and Devel::NYTProf. choroba recently had a nice thread where you can see the B::* stuff at work: Using constants as hash keys.

Best regards, Karl