Your code leaves a little to be desired...

• The formatting is... well... almost non-existent.
• You aren't using -w or use strict;.
• You aren't taint checking.
• You use the CGI module seemingly for one thing: printing out the header. (Why use CGI if you are going to parse the query string by hand?)
• Your program starts with over 50 separate print statements. (Time to learn about here docs.)
• Most of those 50 prints are writing out javascript...
• Your error messages (e.g. open ... ||die("You suck");) aren't very informative.
• Half the time you don't check the return from open at all.
• WARNING! You have introduced a security hole and opened yourself to remote exploits by using tainted user supplied data inside backticks! This is no joke. If that code is up, anyone with access to it via the web can run arbitrary code on your server with the same privileges as the web server itself.

My advice: don't walk... run and take that "code" off your server, delete it, read perldoc perlsec very very carefully, read perldoc CGI carefully, get yourself a copy of perltidy and learn how to use it, get a book on Perl and maybe one on CGI, educate yourself a bit, and then start with a less ambitious project.

I know that's a little rough. I don't mean to be insulting; I just mean to tell it like it is. If you don't listen to the rest of my advice, at least listen to the part about taking that code off your server.

-sauoq
"My two cents aren't worth a dime.";

Take heed of sauoq's sage advice.

Just to expand slightly on matters more 'stylistic'. sauoq's point about perltidy referred to your formatting - indentation etc. It may sound petty ("what the h*ll does it matter how *pretty* my code is so long as it works?") but a geat deal of coding is about stucture. Proper indentation, consistent brace styles and the like all help to make that structure more obvious. Forgive me if some conversion-to-html-then-txt destroyed your already-perfect indentation, but looking at the kind of redundancy etc. that I reckon you would have spotted had your code been 'easy on the eye', I doubt it.

Another thing that makes code 'ugly' and hard-to-read is the mixing up of data and code, making it difficult to find specific parts of both. Here, your data is "print" statements containing (mainly) 'static' stuff. It's much more readable to have something like....

if ($something) {
    print $big_long_something_response;
}
else {
    print $other_big_long_string
}
[download]

if ($something) {
  print "Something happened";
  print "I could have defined this elsewhere in the file";
  print "Or even used one of the fine templating modules...";
  print "...available from a CPAN mirror near you...";
  print "but instead I'm going to print 40 lines of code..";
  print "and make this upcoming 'else' statement..";
  print "really had to find without bracket bouncing all the time.";
}
else {
  print "you're going to have to bracket-bounce this one too..";
  print "to skip what is basically a "do this or this" piece of code."
+;
.
.
}
[download]

Cheers, Ben.