If you maintain a web site for a department, office, or organization on campus, there is a good chance that you can use PHP or Perl on your web pages. PHP and Perl are two very popular scripting languages which are particularly suitable for web development. At BU, most department and office web sites are housed on Bingwww which supports PHP and Perl. On the other hand, personal and course web pages are typically located on Bingweb or use the Blackboard course management system where PHP and Perl are not available. So, to reiterate, Perl and PHP are available on Bingwww but not on Bingweb.

The remainder of this document refers to PHP and Perl as they are installed on Bingwww. The manner in which they are installed on other systems and the instructions for using PHP or Perl on those systems may be different.

Basic Script Requirements

Certain requirements must be met so that your scripts will work properly on the web server. Failure to follow these rules often leads to an "Internal Server Error" message when attempting to view your script.

Location, Location, Location

On Bingwww, your PHP and Perl files can reside anywhere on your account. They don't need to be in a special directory, although it is common to put them in a directory named cgi; however, it is entirely up to you how you want to organize your files.

What's in a Name?

Perl scripts must have a .cgi or a .pl extension. PHP scripts must have a .cgi extension. Because you will be running PHP scripts in cgi mode, you cannot use a .php extension for PHP files.

For example, you might name your file myfile.cgi. If it is a Perl script, you could also name it myfile.pl . Don't name it myfile.html or the system will assume it is a standard HTML file and the code will not be interpreted. If it is a PHP script, the name myfile.php will not work properly either.

Execute This

Basic file permissions are read, write, and execute. By default files you upload to Bingwww will be readable and writable to you and readable to everyone else. Perl and PHP scripts must also be executable at least to you. You may be able to set the proper file permissions using your FTP client. If your FTP client doesn't support this function you will need to log in to your web account using Secure Shell (SSH) or Telnet.

Dreamweaver
Dreamweaver's built-in FTP client does not allow you to change remote file permissions but you can use the Macromedia Extension Manager to install an extension to Dreamweaver which allows you to do this. You can get a list of all the Dreamweaver extensions on Macromedia's web site. Once you've installed the proper extension, from the Files list in Dreamweaver you can control-click (Mac) or right-click (Windows) on the remote file whose permissions you want to change, select "Set Permissions", and a dialogue box will pop up from which you can set your permissions.

WS_FTP (Windows)
If you use WS_FTP (which is part of the BUICK package) for transfering files, you can set file permissions remotely. To do this, open WS_FTP and connect to your web site. Select the file or directory on the remote server for which you want to change the permissions. Click your right mouse button to display the pop-up menu. From the pop-up menu select "chmod (UNIX)". A "Remote file permissions" window will appear from which you can set your permissions.

SSH and Telnet
If you are going to use SSH or Telnet to log in to your web account and change file permissions you should know some basic Unix. After you log in to your account, find the file or directory for which you want to set the permissions. Suppose your file is named myfile.cgi. To set the execute permission on this file, use the following command:

chmod 700 myfile.cgi

The Path to Success

The first line of your script identifies the path to Perl or PHP on the system. This line is required for all of your scripts on Bingwww. For Perl the line is #!/usr/local/bin/perl . For PHP the line is #!/usr/local/php .

Transfer Troubles

If you are using an FTP client such as WS_FTP, Perl and PHP files must be uploaded to Bingwww in ASCII format. Binary transfer will corrupt the scripts. With WS_FTP it is simply a matter of clicking the appropriate button for ASCII before you upload your script. You cannot use ASCII transfer mode for all your files, however, as images will be corrupted if they are not uploaded in binary format.

Dreamweaver users can solve this transfer corruption problem by choosing "Code Format" from their Preferences menu and then setting the "Line Break type" to "LF (Unix)". This only needs to be done once.

Troubleshooting

When debugging your script, it often helps to run it from the command line before viewing it through a web browser until you get it error free . Often the only error message you will get from the web browser if there is a problem with your script is "Internal Server Error". This is a generic error message which isn't very helpful in identifying the cause of the problem. To run your script from the command line, log in to your account, change to the directory where your script is located and issue the following command:

./myfile.cgi (where myfile.cgi is the name of your Perl or PHP script)

This will execute your script and you should see any syntax error messages on the screen. When your script runs without error, it is time to try it out from your favorite web browser. Even though it may be syntactically correct, you may still have logic errors.

If you receive an "Internal Server Error" when you try to view your script in a web brower, first make sure you have followed all the rules listed above. If you can't determine what's causing the problem, you may need to look at the web server error log. To do this, you will need to login in to your account. First run your script again from your favorite web browser. Then, from the system prompt, enter the following command:

tail /local/httpd/logs/website/error_log

Where: 'website' is the first part of your site URL. For example, if your web pages are found at foo.binghamton.edu, then the command would be

tail /local/httpd/logs/foo/error_log

If your web site is busy, you may not see the message the first time - a lot of messages can go to the error log file. If you don't see the error associated with your script, try running the script and issuing the command again until you see it. The messages in the error log often give you a good idea of what's causing the problem.