If you want good answers, you might wish to take the
advice offered here.
Aside from that, at a glance, you don't use strict, you
are using cgi-lib.pl rather than CGI, your temp
file handling has a ton of race conditions, your lock file
handling means that if anything went wrong it would tend
to randomly fall over.
I don't know what specifically causes the (unspecified)
symptoms that lead you to post, nor do I feel inclined
to dig into it deeply enough to figure that out... | [reply] |
What doesn't it do? What does it do instead? Are there
any errors you can report from the error log? What does
the user see? Have you tried running the script from
the command line (setting env variables you need first)?
What was the result of that? Did you write this script
yourself or "borrow" it? Have you tried "perl -cw script.pl"
from the commandline to ensure that the script compiles
correctly and without warnings?
Oh yeah, "use strict;" and "use CGI;" and so on and so forth.
"#!/usr/bin/perl -w" and
--
$you = new YOU;
honk() if $you->love(perl) | [reply] |
This program does seem to have a few problems in the general design area (I have not looked at every line of code).
Heres a few points to look into.
- this is one of the tasks I used to learn perl :). Since then I have made more advanced versions using relational databases and message threads, it is something you can rewrite again and again as learning progresses.
- warnings and strict save lots of time in debugging and sanity.
- cgi-lib.pl is out of date, use CGI.pm or if you can't maybe CGI_Lite.pm
- why do you use a seperate subroutines.pl?
- why do you have four subs (box1,box2,box3,box4) which seem to repeat most of the functionality of each other. Maybe have one sub and pass it an argument for box number and have interpolation and a few if statements to handle any differences between the boxes.
- your language regex's could be joined and should ignore case ie $in{Comments} =~ /dang|damn|bloody|darn/i
- maybe you could have a common error reporting sub instead of pasting it everywhere you need it
- databases - even DBD::CSV - are good :)
- for a full discussion on a working (but not too complex) bulletin board look at merlyn's column.
- try, try again
- if you have any specific problems, please clarify
| [reply] |
As the others have said, the code above has many problems. If
you just want a good working bulletin board, you should probably look
for one of the many that others have already written. If you are doing
it for a learning experience, try to post smaller portions of
code and ask about a specific problem instead of posting the entire
code and asking for "any problems."
In general, writing a good bulletin board is a tricky thing,
and can be much harder than it looks. I've written my own and it's
now at 4000 lines (and growing), and I tend to write
small, efficient code. :) Here are some things to keep in
mind when rolling your own:
- Use a database if possible. It saves a lot of trouble.
- If you can't use a database, keep the data separate from
the html files that are displayed. Keep the html out of
your code as much as possible. Break up the data into
multiple files, and create your own indexes (subsets of
your data) to allow quick accessing of the data.
- Check and double-check your file locking. This part will
really get you in trouble: since multiple processes are
writing to the same file, a simple mistake can cause your
files to be erased.
- Some sort of login/authentication will be needed eventually.
Design it that way from the beginning.
- Abstract everything as much as possible. Adding or removing
an entire table, for example, should involve changing
a configuration file and NOT the code. Things such as
the error messages, the names of the boards/threads,
the "improper language" words, etc. should not be inside
the main code itself.
- Perlmonks is a great resource,
especially for specific problems in large projects. :)
| [reply] |