1. Knowledge Base
  2. >
  3. Results
    4.
  4. >
  5. Article
    6.

Using CGI

What is CGI?

CGI stands for Common Gateway Interface. You can run CGI scripts written in a scripting language such as Perl, PHP, and shell scripts. CGI allows you to add interactive and dynamic content to your Web page. You can have your own WWWBoard to let your users interact, run your own website poll or keep track of your visitors.

Java Servlets - definition and support

Java Servlets are like CGI scripts, except that they are programmed in Java. Currently, We do not support Java Servlets.

CGI - Enhanced Script Library scripts

The Enhanced Script Library contains a click-through counter tool and a Form Email script. Click here to see all available scripts.

Available file extensions for scripts

  • Perl scripts must have a .pl or .cgi extension.
  • PHP scripts can have the following extensions: .php, .phtml, .php3, .php4., and/or .php5
  • Python scripts must have a .py extension.
  • SSI files must have a .shtml or .shtm extension.

The path to Perl (UNIX platform only)

The path to Perl is: /usr/local/bin/perl
 

Note that the CGI servers automatically direct your scripts to this path. You do not need to change the '#!' line at the top of your scripts.

 

Script restrictions

All scripts have the following run time and language support limitations:

  • Run time: All PHP/CGI/Perl scripts are limited to 60 seconds run time. If your script does not complete during that time, it will be killed. We cannot allow custom scripts to impact the performance of other customer sites on our shared hosting platform.
  • Language support: We support almost any Perl, PHP, or shell script. You cannot run CGI scripts written in C++, Visual Basic, or some other language.

For liability and cost reasons, we cannot help you write or troubleshoot your CGI scripts. If you need further help, we recommend that you contact a qualified developer/programmer for assistance.

Read Your CGI Error Log

  1. To access the CGI Error Log, go to Hosting Summary on the top.
  2. Click on Scripting Config on the left pane.
  3. Then, look for the Server Side Includes & CGI tile and click on the Manager Server Side Includes & CGI link.
  4. Next, click View Error Log under Actions. 
View Error Logs
When reading a CGI error log, the first thing to remember is that errors are appended to the end of the error log. You'll need to scroll down to the bottom of the log to see the latest entry.
CGI Error Logs

 

NOTE: Error log entries are limited to approximately 500 characters. This limit is rarely hit, but if you find that one of your longer errors appears to be truncated, this may be the reason.

When your CGI application records an error in your log, a few pieces of information are recorded along with it. Following is an example that has been broken down into further detail:

Sample error: 

20120622T165202: <host name>/file.php Parse error: syntax error, unexpected $end in /path/to/file.php on line 33

The first part of the log entry is the date and time that the error occurred (always shown in Eastern Time):

  • 20120622T165202 = June 22, 2012 at 4:52:02 PM
  • Year: 2012
  • Month: 06
  • Day: 22
  • Time: 16:52:02 PM

The second part of the log entry is the URL to the file that generated the error:

  • <host name>/file.php

The final part of the entry is the error itself:

  • Parse error: syntax error, unexpected $end in /path/to/file.php on line 33

If you're not sure what a particular error means, you may be able to search online to find more information about the error. When you search online, you may need to remove the information that's specific to your site (such as your domain or the server path) to find useful results.


My script worked fine yesterday, but now it says it can't find the path to my files. What happened

As part of our ongoing system maintenance, we sometimes add new devices to help improve the performance of customer websites. As a result of the new hardware, customer CGI scripts (Perl, PHP) and databases that use 'real' directory paths may cease to work.

If you are using real directory paths (paths that start with '/hermes/webxx/'), you need to replace them with the correct symbolic paths ('/home/users/web/'), which are fully compatible with our shared hosting architecture.

If you have any questions or need assistance updating your paths, please contact us, and we will assist you.


Why is my script returning a Server 500 error

Explore the following possibilities to troubleshoot:

  • Does your account include CGI accessibility?
  • Did you call your script with the correct URL?
  • Did you upload it to the correct directory?
  • Does your script expect values? If so, did you use the right method (POST/GET)?
  • If you edited path variables in the script, are they correct?
  • Are you sure you uploaded the script in ASCII mode? You will have to upload them in ASCII mode to make them work.
  • It's possible that the .htaccess coding (if coded improperly) could be causing the 500 error.


Language support restrictions

We do not provide support for custom code or custom scripts. We assume that if a customer wants to use Perl, CGI, PHP, Python, ASP, or any other scripting language, he/she has the necessary programming skills to manage these scripts. The tools we provide are meant only for advanced users and for users who are knowledgeable enough to manage their scripts using those tools.

If you have limited experience or knowledge about server-side scripting and troubleshooting custom code, we strongly recommend that you look into hiring a web developer to assist you. As your host, we are only responsible for hosting your files on our platform and providing the proper hosting environment (See our Terms of Service here).

There are, however, several exceptions in which we will consider troubleshooting your custom code/scripts. If your issues resulted from any of the following, we would do our best to assist you:

  • Platform Migration - In cases of upgrading or switching platforms. We will troubleshoot scripts that worked on the old platform prior to migration but do not currently work on the new platform (Only within 2-3 weeks after migration).
  • FormMail.pl - We can attempt to troubleshoot individual copies of the generic FormMail.pl that is available from open source repositories on the Web. Yet, we cannot troubleshoot this script if it has been extensively customized or if it is not the most recent version v1.92. Also, we cannot support other form processor script issues using our mail programs: Sendmail and PHPMail. We recommend and will support our form processor script (For more information, go to your PowerPack or click here).
  • Servers - Scripts that worked for weeks/months and have no modifications done but suddenly stopped working.
  • Scripts - All server-side scripts which we provide as a part of your plan.
  • Fulfillment - If your plan includes access to CGI and/or another server-side scripting, but no scripts function on your account.


Host RSS files

Since RSS is a file format and not a scripted language, you can publish RSS files in your web directory directly. To automatically generate an RSS file based on your website's content, you can use a server-side script (CGI, PHP, Perl, or ASP) or the RSS file can be generated by a client application running on your local PC, or it can be generated by hand.

Chat
Close