WebHosting Transfer Cgi-BIn Folder. Can't even get .html to work!

[veneficuz]

Ok, :breathe:

I've been trying to transfer over a site that uses I believe Perl/.cgi. there's a folder called cgi-bin; where even with 755 chmod, and uploaded ascii transfer. I still get a blank page. Also I believe I have the !/usr/bin/perl directory setup correctly.

Also I can't even run a simple .html file out of this directory.
And when I take it out of this directory, the .html file works, but then it asks me to download the .cgi file??

I am blowing steam out of my ears, and would appreciate some help.

[KevinADC]

The server you are transfering to has to setup the cgi-bin folder. If they do not have one you can't just add it and expect your cgi/perl scripts to work.

[veneficuz]

Thanks for the quick response,
I've talked to the hosting company aplus.net many times, they say it should work, or that I need to update my script file to the newest version. The CGI-BIN was already there because I am transferring one site to this new host.

I am simply transferring my files to a new host, but the cgi files do not work. they come up with a blank page.

[KevinADC]

according to aplus.net, the path to the perl interpreter is:

#!/usr/local/bin/perl

for unix servers. Why you get just blank pages is strange. Can you check the server error logs?

[KevinADC]

if you are on an NT server, name your scripts with a .pl extension instead of .cgi, and no shebang line is necessary.

[veneficuz]

Ok, im going to restart and upload everything with cuteftp, and make sure everythings setup right.

This is an older script probably 5 years, would that make a difference??

If it doesn't work again then is it a mystery?

Trying to find my logs..

my Email is badmotherwhat@yahoo.com.

I would really appreciate the help.

[KevinADC]

This is an older script probably 5 years, would that make a difference??


It could, but the blank page is still unusual. Did you look at the source code of the blank page to see if there is some html tags even though there is no visible content in the browser window? Are there any databse connections involved? Try the simplest script possible:


#!/usr/local/bin/perl
print "Content-type: text/html\n\n";
print "Hello world";

name as test.cgi and test.pl and see if one or the other extension gets it to work.

[FishMonger]

if you are on an NT server, name your scripts with a .pl extension instead of .cgi, and no shebang line is necessary.

NT doesn't need the shebang line, but Apache does, even on an NT box..

[veneficuz]

i finished with the fresh upload, its a unix based host.

I get a blank page on the test.cgi, *EDIT test.pl is also a blank page.

silly Quick question WHere should my /usr/local/bin/perl folder be located, or is this some code that needs to be there.

will keep u updated, if i figure something out.

[KevinADC]

NT doesn't need the shebang line, but Apache does, even on an NT box..

It can be setup so no shebang line is necessary. I don't know if the NT http servers on that host are setup like that but the FAQS seem to indicate they are:

quoted from:

http://www.apluskb.com/scripts/Using_CGI_Scripts_Perl_answer400.html

Using CGI Scripts (Perl, Unix shell, etc.)

The most common way to create dynamic content is to use CGI (Common Gateway Interface), which is the web server that executes a program generating an HTML page as output. There are two methods used to pass information (such as the content of the input fields in a form) to the program: GET and POST. The information is encoded and needs to be decoded. There are common libraries for Perl, C, etc. for handling CGI input.

In your web page you need to reference the CGI either as link or as ACTION in the form tag if the CGI is supposed to handle a form. Example:

<FORM METHOD="POST"
ACTION="http://www.yourdomain.com/cgi-bin/file.pl">

On NT web servers, script file extensions are associated with the interpreter for the language (e.g. - .pl files are associated with Perl and will be directly executed).

On Unix web servers, the scripts need to begin with #! and the interpreter location (e.g. Perl scripts must start with the line #!/usr/local/bin/perl ). Also, the scripts must have executable permissions for the web server - after you upload the scripts, FTP to your web server with your username and password, and change the permissions to 755. Some FTP programs support changing permissions with a function named “chmod” or simply “change permissions.”

[KevinADC]

i finished with the fresh upload, its a unix based host.

I get a blank page on the test.cgi, *EDIT test.pl is also a blank page.

silly Quick question WHere should my /usr/local/bin/perl folder be located, or is this some code that needs to be there.

will keep u updated, if i figure something out.


Normally you don't need to be concerned with the path to the interprter, /usr/local/bin/perl, other than to know what it is. The hosting service is responsible for having that setup correctly for you to use. Try:


#!/usr/bin/perl

and see if that gets the script running. It wouldn't be the first time a host had the wrong path to perl listed in the FAQs page. Also, find and check the server error log if possible.

[FishMonger]

Kevin,

If IIS is being used, then shebang line is not needed/used. However, it is required for Apache. If run from the Windows command line, then the shebang line also not needed. It's only Apache (and maybe a couple other web servers) that require the shebang line, i.e., the requirement is application specific.

[KevinADC]

Kevin,

If IIS is being used, then shebang line is not needed/used. However, it is required for Apache. If run from the Windows command line, then the shebang line also not needed. It's only Apache (and maybe a couple other web servers) that require the shebang line, i.e., the requirement is application specific.

Wow, this is one of the very few times I can say you are not correct Fish.

http://www.developer.com/open/article.php/625861

start quote----

ScriptInterpreterSource

On Unix, the first line of a script file, such as a shell script, or a Perl program, indicates what interpreter is to be used to run the program. That line will look something like:

#!/usr/bin/perl

or

#!/bin/sh

Windows has no concept of looking for the #! ("shebang") line, but does everything based on the file extension.

Apache lets you do things either way, as you like. If you are aiming for platform independence, it is very handy to be able to use the #! line, so that you can run your CGI programs on your Windows machine, and also on your Unix machine. But, if you are developing CGI programs only for Windows, then perhaps this does not matter to you, and you want it to execute based on the file extension.

The <#item_ScriptInterpreterSource>ScriptInterpreterSource directive tells Apache which one of these you prefer. The default value, script, tells Apache to look for a #! line to find out what interpreter to use to execute the program. Setting it to registry will cause Apache to look in the registry for the association between the file extension and a script interpreter to run it.

end quote-----

I assume the same is still true for Apache 2.x version, but the directive might be called something else.

[FishMonger]

Wow, this is one of the very few times I can say you are not correct Fish.

I bet you're really enjoying that. ;) :)

[KevinADC]

hehehe.... no..... well, maybe a little bit. ;)

Actually, this was something pointed out to me a couple of years back when I insisted apache needed to have a shebang line too. :)

[veneficuz]

seem to be getting this error :
Premature end of script headers

[KevinADC]

seem to be getting this error :
Premature end of script headers

If the script I posted for you try gets that error, about the only thing it can be is the path to perl is wrong or you uploaded the script in binary mode instead of ASCII (text) mode.