Hi, Ytrew here.

Since you sound so eager to learn about perl, I'm going to try to turn this into a bit of a longer explanation than a one line fix. I'm going to try to first explain what the situation means, the good way of solving your problem, and then the easy way of solving it. The method you choose will depend on how much work you want to do.

First of all, because it sounds like you might be confused about this, the verb "requires" in the error message doesn't relate to the "require" function in perl. In this case, "requires" just means "needs".

When you use strict, perl gets pickier. In your case, its complaining because you didn't specify which package your global variable ($admin_dir) belongs to.

By default, if you don't use strict, any variables that you don't mark as local with the perl functions "my" or "local" are global variables in the main package. But when you do use strict, you need specify which package the variable belongs to. You can do this by putting the package name, and two colons before the variable name. (Eg. $admin_dir becomes $main::admin_dir). For the special "main" package, you can skip the word "main", and just write $::admin_dir every time you have $admin_dir in your code.

This method is good when you have only a few global variables in your script. It tells you at a glance which variables are the rare global ones, and which package they belong to. It's considered good programming style to limit the number of global variables in large programs. After all, if you have only two variables that could be causing a bug, it's easier to figure out which one is wrong than if you have two thousand. So, the ideal way to handle your situation is to re-work the code so that it has only a few global variables, and mark those explictly.

That can be a lot of work. So, the easy way is to just tell perl which variables are globals variables within the current package, using either "use vars()", or the newer "our" command. When I look up the documention on vars (perldoc vars), it suggests using the "our" command instead. It's usually quite wise to listen to perldoc, so that's what we should do.

So, the easy answer is to put a line like "our $admin_dir;" at the top of your file, to explictly state that you intended for $admin_dir to be a global variable within the current package.

You'll still have a bunch of global variables, but at least you'll have a complete reference of which ones they are that's all in one place, at the top of your file. Ideally, if you have time, you can examine each one, and determine if it should really be a "my" variable instead. If you don't, well, at least you've managed to use strict, and that's the first step to catching a whole bunch of coding errors.

Good Luck! Hopefully, this was of some help!

-- Ytrew Q. Uiop