Site Root : cgi-minihowto

Skynet CGI FAQ

Over the last number of years a couple of people have been having trouble with their cgi scripts and asking me and others questions, Heres a few of the most frequently asked questions and their answers

  1. What's this "Internal Server Error" stuff
  2. This is just a generic message, in practically every case it means that youve made a mistake in the perl (or whatever) script or in the web page that launched it.
  3. It's a perl cgi and it is isnt working
  4. The first line of the scripts state where the interperter is, most of the perl ones youll get will say
    on skynet (and most linux boxen) perl is located in /usr/bin so change line 1 to
  5. That still didn't work
  6. Permissions are usually really wrong, not alone must your public_html be chmod a+x so that the webserver can change dir to it, so must ~/public_html/cgi-bin and the cgi scripts themselves MUST be chmod a+x so that they can be run! Also if you chmod a+w on them then the webserver will not run them as its a security risk for you. So setting all permissions on is not going to work.
  7. Still not working
  8. Bloody dos ^M, if you use a perl script written in dos or that class of os, and uploaded to skynet then it too will fail as there's shit chars in there that dos uses that linux (and unix in general) doesn't, the dreaded ^M's, they dont display in many unix editors so you might not be aware of their existance, vim users can use vim -b to see them, the best thing to do if you dont know whats going on is to do
     ~caolan/strip_cr random.cgi 
    thatll remove the ^M's if they're there.
    Uploading the cgi file itself from dos to unix using ftp with the ascii option on instead of binary does this automatically, which is why the option exists in ftp.
  9. I don't know why the program is failing, how do I find out ?
  10. There exists an error log of httpd disasters on orac that you can look at. First telnet to, the machine where the webserver is run from. Now for example in one term do
     tail -f /services/entity/logs/error_log 
    and a continous list of errors will flow by you as they happen, the best thing is to do
     tail -f /services/entity/logs/error_log|grep username
    replace username with your own, now youll get errors belonging to you. now try and access your cgi and see what happens, you will get useful info if theres a problem that the webserver encounters with your cgi. ctrl-c will kill that listing btw.
  11. I still cant get it right
  12. Make sure to edit the launching html file to show the location of your cgi script.
  13. Ack bloorgle, I'm going to go absolutely mad, run amock and shove this cgi so far up the ass of the first person i meet, it just doesn't work.
  14. It can be handy in your telnet session to actually run the cgi raw, i.e
     cd ~public_html/cgi-bin
    and see does it even try to run, it wont work properly in most cases as you wont have passed any arguments to it, but it should spit something like html out, not
     "error on line 10"
    if it does then there's your problem on line 10,
  15. I get a "malformed headers" error message
  16. If the script doesnt work, and you get malformed header as the error message from the tail on on the error log that you should be doing, then remember that the first line of output should be
     Content-type: text/html
    there should be a blank line after that befome the html starts. (There are other options for Content-type, but thats the most usual one)
  17. I still get "malformed headers"
  18. If the owner of the files is different that the user whose cgi-bin dir there are in, then you'll get this message. This probably will only happen to incompetent sysadm trying to help folk by leaving scripts owned by root in other peoples dirs, so remember to change the ownership to the user himself.
  19. What language should I write cgis in
  20. You should write cgi scripts in perl or sh or some scripting language rather that c/c++ as if you do then if the website is moved from one architecture to another then they will work fine, otherwise they wont, and youll have to recompile. The reasoning here is that we might get a sun box someday, and the website would move onto it. but of course it might move back in case of failure of one computer or for other reasons, so keep those cgi's in perl or sh or something of that nature.
  21. I wrote it in c/c++ anyway and its still not working and I did everything else I was supposed to
  22. Maybe, just maybe you are returning a non 0 value from your c code, or have defined main as void main(void) which i believe they happily teach you to do happily in certain unnamed courses, but this can cause grief as the return value is undefined, and some webservers give out if the cgi doesnt return 0 (success) and gives errors.
  23. My script which calls another program doesnt work, but the program definitely is installed on skynet.
  24. The webserver runs on which is currently a different machine from which is on The program probably isn't installed on that machine. Both machines should share the same /usr/local and the user directories. While there are similar installed software on both, the webserver probably has a smaller set of programs installed on it. Shout at the sysadm about this.
  25. General advice.
  26. If you want to write cgi's using perl or anything, dont aimlessly fart around pushing lines of perl all over the shop, adding 200 and then run it and be surprised it doesnt work, do it one small bit at a time, line by line if you're new to it, very few write more than a few line of anything without an error, and with cgi's it can be hard to track down whats wrong.

Caolan McNamara (1999) <>

Last generated at Sun Feb 7 00:44:59 2016 Caolán McNamara <> Created with WebMake/0.5