Interactive Scripting with CGIwrap

CGIwrap is a gateway program that allows general users to use CGI scripts and HTML forms without compromising the security of the http server. Scripts are run with the permissions of the user who owns the script. In addition, several security checks are performed on the script, which will not be executed if any checks fail.

CGIwrap is used via a URL in an HTML document. As distributed, CGIwrap is configured to run user scripts which are located in the ~/public_html/cgi-bin/ directory.

The Alumni server is apache based and supports the popular scripting languages such as perl (perl-5.6.0) and c; we also enable support for php and python (Python-1.6). perl is by far the most used language.

CGIwrap - User Instructions

The following are instructions for setting up your account to be able to use CGIwrap to execute CGI scripts. It is assumed that you are familiar with writing CGI scripts and writing HTML documents for the WWW. In the following instructions, the following information is assumed:

UserID: class1900
Home Directory: /alum1/classes/1900
CGI Directory: /alum1/classes/1900/public_html/cgi-bin
Name of Script: script.pl
Web Server: www.dartmouth.org

If you do not already have a cgi-bin directory set up, create one inside your public_html directory.

Install your script into the cgi-bin directory

~class1900/public_html/cgi-bin/script.pl

The script is executed using the following URL:

http://www.dartmouth.org/cgi-bin/CGIwrap/class1900/script.pl

If you wish to see debugging output for your CGI, specify CGIwrapd instead of CGIwrap, as in the following URL:

http://www.dartmouth.org/cgi-bin/CGIwrapd/class1900/script.pl

CGIwrap FAQ

I am getting a 500 Server Error, how can I debug my script?

CGIwrap supports a debugging mode which can help to debug scripts. To use it, call CGIwrap via the URL http://.../CGIwrapd/... instead of http://.../CGIwrap/....

I am getting the error execv() failed

This generally results from either having the wrong path to perl, or having control-M's after the path to perl. This is usually a result of uploading the script in binary mode instead of ascii. You can fix this by re-uploading the script in ascii mode.