Answers to general questions on running CGI scripts and programs. This is primarily about scripts, but you might find something here that will get that C program working too. It is under development and may not be totally organized, but if it gets your script running it has served its purpose.
If you save this page for later local viewing with your browser, change the filename extension to .htm or .html
This page was last updated 1/1/99
First you should contact your provider to see what is required for CGI scripts. Some will not let you run them due to security risks from poorly written scripts. Others require that they be in a central /cgi-bin directory. On our system, they can be placed in any directory accessible by URL (public_html or lower).
The default for most UNIX servers is that the filename must end with '.cgi' whether it is a shell script, perl script or C program. Your provider would have to tell you if other script names are acceptible. I am not familiar with Windows servers.
Always test your script in the shell or system before putting it on the Web. The error messages will be much more meaningful than "Server Error" (if I had a dollar for everytime I forgot a semicolon or quote...). There are also perl versions for DOS/Win and Mac which are very helpful for testing search and substitution strings at home to save phone time. See more on testing below.
The first line of a script looks like a comment because it begins with "#", but it is important to modify this line to point to the proper program to interpret the script. A UNIX script must begin with "#!" (followed by optional space if desired) and then the path/program that it runs under.
Typical first lines for perl might be:
To find where perl is type 'type perl' or 'which perl' in the shell. To determine the perl version type 'perl -v'. Our system has perl5 at /usr/local/bin/perl and /usr/local/gnu/bin/perl.
The server is usually logged in as 'nobody', so a script usually has to have world execute permission (chmod 755 foo.cgi or 705 may work).
Any file you write to from a CGI script usually has to already exist and have world read and write permission (chmod 666 write.txt or 606 may work). It may be possible to create temporary files in a directory with world write permission.
Scripts that are run setuid as you can create, read and write files with your own permission, but they also have other requirements. With an suid C wrapper you can run scripts with 700 permission that access files with 600 permission. The camel book (< I>Learning perl from O'Reilly & Assoc.) explains this in more detail.
DOS terminates lines of text with a carriage return/newline pair (^M^J or \r\n). UNIX terminates lines of text with just the newline (\n) and gets confused by the carriage return. So if you edit a script in DOS/Win and then simply upload it (binary) to UNIX, it will not run unless you strip off the carriage returns.
Some communications programs can be set to automatically convert ^M^J to ^J if the file is uploaded as ASCII text. For example WS_FTP will automatically convert text files between systems if in ASCII mode or Auto mode with .PL and .CGI added as extensions to send as text. However, files will not be converted if you use a binary protocol like zmodem. So I wrote a script called [dos2unix.pl] that will convert text files from DOS to UNIX, after they are uploaded.
You should test the script from the shell, where you will get more meaningful error messages. Note that shell paths may be different from server paths and you will not have server environmental variables when testing in the shell. So may either need to include temporary test variables in the script or temporarily add a statement to get them from STDIN.
This works best if the current directory (.) is in your path. A file called ".profile" sets your path on login and ".cshrc" contains the path before running any C shell program or script. If you edit either of these files, back them up first and if you use an editor that wordwraps, make sure you get the entire path statement back onto one line. See the book Open Computing - UNIX Unbound from Osborne/McGraw-Hill for more info.
Otherwise you should be able to get a script to run in the shell by putting the current directory in front of it as in './foo.cgi'. If you can run it as 'perl foo.cgi', but get "file not found" when you try to run it as ./foo.cgi, then either the first line is incorrect or you have not stripped the carriage returns (it is looking for "perl^M" instead of "perl"). Perl error "eof in file" may also indicate unstripped carriage returns.
A link to a script should be a relative or full URL path from the page that calls the script.
Paths on a CGI generated page should be full or relative URL from the script location unless you include a BASE reference in the <head></head> for a different location. It may be best to include the whole URL path for links and image sources in CGI generated pages so the browser can find the images even if you move the script.
Paths for files you open in a script for reading or writing should be UNIX or system paths relative to the script or full path from root (which may differ from your shell root).
Of course the most important test is whether it works on the Web. If not, you might also check my [Page Counter FAQ], under [Broken Counter] for an 'sh' script to check paths.
[ Top of Page | Home Page ]