use vars qw/$admin_dir $several $other $global $variables/; But remember that you should rethink your design if you find subroutines changing those after initial configuration.

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

Yo - many thanks for taking the time to write a full explanation and not just a "read a book" type of reply!

I have since found a debug wrapper, placed it in my very messy index.cgi file and laboriously gone through all the error messages and declared the various vars, arrays and hashes as either 'global' or 'my' - according to my existing code (haven't got time to re-write this one!).

I have learnt a lot over the last 2 weeks, but it's still not enough! I've got 2 weeks left to find the bugs, tidyup my code, learn, translate the language libraries, put it all together, sell it to the local businesses, and make sure the cheques don't bounce, otherwise I'll be looking for a new place to live!!!

Anyway, less of that! i'm on the tail end of a 30 hour day and my caffeine level is dangerously low!

I've got the infamous "Camel Book", my browser instinctively knows when I need to lookup CPAN, Perldocs, etc... and I think even my cat is starting to write his own code!

The difficulty I think is that there's possibly just too much info 'out there' nowadays, that one could very easily find themselves spending weeks in finding an explanation to their problem which hits home - different people, different styles, etc... My problem!

Even with this debug wrapper, I'm still getting (every now + then) a blank screen - no clues, no data transfer, no entries in the error log - so, no idea what it is or where to start looking for it! And no command-line access either!

Also, the app that I'm doing is rather large to say the least! Multi-lingual, multi-user, minimum of 2 login interfaces, (3 if you include mine - being the 'God Admin') multi-level subscriptions, multi-level marketing, different business bases..... I've definately bitten off far more than I can chew with this one! Talk about megabites!

Believe it or not, I've spent 3 years+ on this thing! 5 complete re-writes, learning, programming, disecting other peoples scripts, plagerising (?) looking for help, etc... I should have just contracted an Analist/Programmer from the beginning! (U know anyone?) ;-) And I'm now having big 2nd thoughts that I should have gone the php/mysql route from the start!

Anyway - yes, your reply was of help! Thankyou. It helped by confirming what I'm currently doing. At least I now know I'm not going down yet another dead-end street! (living on one's bad enough!).

One day I hope I'll be in a position to help out others who are just starting out.

The saga continues... The search for knowledge goes on, and so does the desire to have staff!

Grindstone is calling for nose to be put on it!