What web server are you using?
Have you checked the logs?
Perhaps you don't have access to the web server or its logs; this is not entirely uncommon, as I understand it.

But understand that even though the script is meant to run through CGI, you still have ways of testing the script. Chief and most basic among these means is perl -c script.pl. The -c switch will not attempt to run script.pl, but simply test its syntax and return its 'compilability".

Running this against your script, I see

syntax error at C:\script.pl line 15, near "result substr"
[download]

Also, please, for your own sake, add a die clause to your open line : open FILE, "user/test" || die "Can't open file! Perl says '$!'".

Talk with your web server admin and see if you can get access to the log files. If not, learn to rely on CGI's command line mode, or set up a similar server on a machine you control.

Also, please, for your own sake, add a die clause to your open line : open FILE, "user/test" || die "Can't open file! Perl says '$!'".

Better make it

open FILE, "user/test" or die "Can't open file! Perl says '$!'";
  or 
open (FILE, "user/test") or die "Can't open file! Perl says '$!'";
  or
open (FILE, "user/test") || die "Can't open file! Perl says '$!'";
[download]

This is probably one of the most commonly committed Perl coding errors, made by novices and the reasonably adept alike. In the case of
open FILE, "filename" || die $!;  #ERROR - DON'T USE THIS the || version of 'or' tries to evaluate the thing immediately to its left, which is the the filename argument, "filename". Since that string always evaluates to true (in the boolean sense), the die will NEVER be executed, even if the  open fails. The or operator has a lower precedence than ||, so it can be used without parenthesis. I suggest using or for short-circuit error checks. Providing the args to open & die are correct, it will always do the right thing.

Your script does not compile, which is a guaranteed way to get a 500 error!

C:\>type test.pl

#!/usr/local/bin/perl
use CGI ':standard';
print header();
print start_html();
open FILE, "user/test";
    for $line (<FILE>) {
    if (index $line, "gold" > -1) {
        $GoldLine=$line;
    }
}
close FILE;
sub getgold {
    my $start= index $GoldLine, ":" + 2;
    result substr $start, length $line;
}
getgold;
end_html();

C:\>perl -w test.pl

Argument "gold" isn't numeric in numeric gt (>) at test.pl line 8.
Argument ":" isn't numeric in addition (+) at test.pl line 14.
Unquoted string "result" may clash with future reserved word at test.p
+l line 15.
syntax error at test.pl line 15, near "result substr"
Execution of test.pl aborted due to compilation errors.
[download]

Rather than explain these all these errors to you it may be more productive if you just explain exactly what you are trying to do and (vital) supply a sample of the data in you file 'test'. I'm afraid that as well as not working your code does not make a lot of sense in its current form.

BTW: If you had inserted a -w flag and used CGI:Carp you would have had these problems pointed out to you. You will generally have a much more rewarding CGI experience if your code starts:

#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
[download]

tachyon

• Check that the script compile (as tachyon pointed out)
  (use warnings and use strict and -T never hurt if you got some input)
  with perl -cw script.pl
• If your script was FTPed from a box with a different OS from the one running on the box where you're executing the script, check for added invisible character
  (EOL problem for DOS->UNIX transfer...)
• Check that the path to perl interpreter is correct
  (otherwise you'll get a error 500 page and a 'no such file or directory' in your web logs...)
• In all case check the HTTP server logs for more detailed error messages.

The sad thing is that I do not know. I wrote the code using examples of different code and twisted them to my own ends. If you can explain what they do and why one would create a sever error it would be greatly apreciated.

I'm not sure exactly what you want to do here, but as it stands, this part of your code doesn't do anything.

sub getgold {
    my $start= index $GoldLine, ":" + 2;
    return substr $start, length $line; #changed 'result' to 'return'
}
getgold;
[download]

return ends the subroutine and passes back it's arguments. So, for this to do something, you will want to get the result of the subroutine by saying $result = getgold; or some such.

So now, $result will contain a string from 2 characters after the ':' in $GoldLine to the end.

Its good programming practice to use parentheses on funtions to make it clear what you're doing. So, you should say substr($start, length $line) instead of substr $start, length $line to be more explicit.

Update: Oops, that probably isn't doing what you want. The first argument to substr is the string that you're operating on. So, assuming you want to find a substring of $GoldLine, you would really want to say substr($GoldLine, $start, length $line). Also, if you omit that 3rd parameter, substr returns everything until the end of the string. So, you can just say substr($GoldLine, $start).

Also, if you want to see errors in your web browser instead of the dreaded "500 Server Error", add the line use CGI::Carp qw/fatalsToBrowser/; at the top of your script. Note that this only prints runtime errors; compiliation errors will give a rather unhelpful 'compilation failed' message.

If the program runs correctly from the command line then you probably have some trouble with the CGI environment, which could be file permissions of the program or the file you are reading, or perhaps misconfiguration of the web server. You could also be missing the CGI module.

If I were you I would put a print "Content-type: text/html\n\nTEST"; at the very top before your use statement. If you still have this error your permissions, or perhaps using ".pl" when your server wants ".cgi", or your perl path (try which perl at the unix command line) or something else outside your program is the problem. That print statement will also let you see if the header command is working.

One thing for sure, if you are only testing your program by running it from a browser, and the use statement fails, you will never be able to figure out what is going on without printing the header manually first. The minimum program is much smaller than what you have, just the first couple lines I would say.

One nice method of seeing the error would be to run the script from the command line. CGI.pm will prompt you for any name=val pairs to emulate a form submittal, just Ctrl-D to break or pass dummy vars to get past the prompt.

this technique works on Unix and windows systems