I think it is copy/paste cargo-cult stuff, that should be replaced by modules

$catagory
[download]

# Define Variables

$basedir = "$ENV{'DOCUMENT_ROOT_OLD'}/www/myfile";
$baseurl = "http://www.whatever.com/myfile";
$cgi_url = "http://www.whatever.com/cgi-bin/perl.pl";

$mesgdir = "messages";
$datafile = "data.txt";
$mesgfile = "myfile.html";
$ext = "html";

$title = "My File";

# Done
[download]

The original code was from a friend who modified Matt Wright's WWWboard code a little

Well, that's the problem right there. There have been numerous comments about "Matt's Scripts" here at the monastery, including statements like:

• When I think of visible Perl code with poor security, I think of the original Matt Wright script archive code, before the NMS project. (from Re^4: A Vision for Easy Web Application Deployment for Perl)
• Take (Matt Wright's book) on your list and be very careful NOT to read it. (from Re: Perl CGI and books)
• I too made the mistake of buying Matt Wright's book when I was first dipping my toes into Perl. (from Re: Re: Perl CGI and books)
• I just have reiterate what other people have said about Matt Wright's book. Don't even open it until you've read all of the other ones. Only then will you be in a position to see just how bad it is. (from Re: Perl CGI and books)

The last three quotes come from the same thread, which you might want to look at because it also provides a number of very useful resources (although it's now 6 years old).

Note that the NMS project mentioned above can be found here: http://nms-cgi.sf.net/ (UPDATE: actually, a better link would be: http://sourceforge.net/projects/nms-cgi/, which shows clear evidence of fairly recent maintenance by our esteemed davorg, among others.)

Bottom line: with regard to the code in the OP, the best course of action will be to ditch it and start over, using some better prototype as a starting point.

(UPDATE: I think it's worth pointing out that the name "NMS" derives from "Not Matt's Scripts".)

Probably someone could update the script or replace it for you. That would be work for them and you might not learn much. A big part of the this site is people helping other people learn.

Learning to write code takes time and practice.

Learning to read, understand, and modify someone else's code takes still more time and practice.

Learning to write code that is easy for other people to read, understand, and modify takes still more time and practice.

Don't quit learning just because something isn't easy. A number of links to suggested reading were posted earlier in this thread. Take a break from this particular problem to learn and practice. Read tutorials. Write small scripts to try the things you read about. Come back to this problem later (say after a few days or a week) and it will appear less complicated.

What I am trying to accomplish is to ... write data gathered from an html form to a user selected directory from the same form...

How many different users do you expect? Will each user start with their own personal "home" directory for their 27 subdirectories? (Obviously, I think it would be a bad idea to allow all users to make or use the same set of directories -- you're bound to get two or more people who want to use a path called "stuff" or whatever.)

For that matter, does it really make sense for the user to make a deliberate choice about which subdirectory to use for a given submission? Would it make more sense for the directory choice to be "automatic" (e.g. based on some other aspect of the submission)?

I didn't see anything (in any of your posts on this thread) that shows the html for the input form itself. How many pieces of input is the user providing when the form is submitted? What else does the user get to do besides submit stuff that will be stored in a file? (For example, what do they do next, after storing something to a file?)

In terms of "understanding scriptng", the basic structure of any CGI application goes like this:

1. Look at the input parameters (use CGI to do this easily)
2. Do something appropriate on the server based on what the parameters tell you (e.g. read from file(s) or from a DB, write to file(s) or DB, do some arithmetic or string editing or ...)
3. Send some suitable response back to the client (send back a confirmation page, or another instance of the current form, or a new form, or redirect to some other page, etc). Sending back html data for display involves printing to STDOUT; the CGI module helps with this too, but various template modules (e.g. HTML::Template) are also good.

That's pretty much it. The rest is just structuring the task based on: what you need to present to users, what you expect to get from users, what to do when they don't send you what you expect, and what to do when you can't give them what they need.

If that's not enough to help you get a fresh start, I think the best course of action will be to start a fresh thread, with a different question and (if possible) a different initial attempt at perl scripting -- maybe start with some example from NMS or the CGI module manual page -- and maybe some more detail about what you're really trying to accomplish.

Oh, I know the CGI man page is huge -- it's a book all by itself -- but you'll be glad when you get familiar with how well it's organized and how useful the examples are.