Forum Moderators: coopster & phranque

Message Too Old, No Replies

Script is throwing in another directory which it not supposed to

CGI/Perl Script

         

Ginaj

10:21 am on Apr 25, 2003 (gmt 0)

10+ Year Member



I have installed a script, and when you use the script it throws in another directory after /cgi-bin/directory/script.cgi

when what it should say is: cgi-bin/script.cgi

This is the config part of the main script
___________________________________________________
local %config;
#-#############################################
# Configuration Section
# Edit these variables!
# The Base Directory. We need an
# absolute path for the base directory.
# Include the trailing slash. THIS SHOULD
# NOT BE WEB-ACCESSIBLE!

#- This is the folder path to your auction folder, NOT A URL
# Place a # at the beginning of the line that you are NOT using
# For UNIX Server
$config{'cgi-path'} = '/home/XXXXXXX/www/cgi-bin/';
# For Win Server
#$config{'cgi-path'} = 'c:/XXXX/wwwroot/cgi-bin/';

$config{'basepatha'} = '/home/XXXXXX/XXXXXX_Data'; # No trailing slash
$config{'basepath'} = '/home/XXXXXXX/XXXXXX_Data/'; # Same as above but with trailing slash
$config{'wwwpath'} = '/home/XXXXXXXX/www/'; # Path to your web folder(where index.html is)
________________________________________________________
Anyone have any ideas as to why this is happening and how I can fix the problem.
It is a UNIX server, all files were loaded in ASCII and chmod to 755 except the data file which was chmod 777

Thanks
Gina

[edited by: Ginaj at 10:52 am (utc) on April 25, 2003]

mat

10:31 am on Apr 25, 2003 (gmt 0)

10+ Year Member



Hello, and welcome to Webmasterworld. You should edit your post to remove all URL's and site specifics - they are not allowed here, nor are site reviews.

Please read the welcome post [webmasterworld.com] .

mat

10:36 am on Apr 25, 2003 (gmt 0)

10+ Year Member



... to address your problem, you need to experiment with the variables in the script - your home, web-root and the like - it is most probably one of those that is causing the incorrect path.

ShawnR

12:27 pm on Apr 25, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Sorry you got the response you did... but Mat is right...

Anyway, to your question...

A bit of a catch 22, as you followed mat's instructions and removed some of the info, which makes it harder to figure out what the problem is. So just guessing here: Is there a $config{'auctionurl'} parameter that you should set? Check that you set it correctly. Make sure it doesn't have the superfluous '/directory' in it. If that doesn't help, post more info, such as:

- Which bit of shareware/opensource software you are using
- What you set the parameters to (all the params, not just the ones you listed in your first post) (just substitute your domain with 'www.mydomain.com').

Shawn

Ginaj

1:33 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



Hi Shawn
I had a look at the $config{'auctionurl'} and it had = "mydomain.com/cgi-bin/auction/auction.cgi
so I removed 'mydomain.com' reinstalled it on the server and still the same problem.
I don't think I can tell you which software it is because of the name of it. But it is GNU GPL.

The only parameters I had to change were the ones in my first email and the $config{'auctionurl'}.

The rest of the script sets all needed directories and data.

Sorry it is not much help.

marcs

1:37 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



I had a look at the $config{'auctionurl'} and it had = "mydomain.com/cgi-bin/auction/auction.cgi

If the extra directory after cgi-bin you want to remove is 'auction' then change auctionurl to

/cgi-bin/auction.cgi

Ginaj

1:58 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



Tried that one also, but it is still throwing that directory in there.

So what you get again is:
[mydomain.com...]

when it should only be:
[mydomain.com...]

mat

2:44 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



Again, my money is on the basepath and basepatha variable declarations in the script - try changing those and see what that does to the path.

Ginaj

2:54 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



I have just uploaded a script to debug cgi and quess what, when you call the script into action it also throws in that extra directory. This script was just a straight upload into the cgi-bin, no basepaths needed to altered, nothing. So, perhaps this is a server problem?

mat

2:59 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



Yes, a server/usage issue - check their instructions, it may have something to do with suexec - assuming you're on Unix hosting.

ShawnR

3:11 pm on Apr 25, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



So all you need to do to fix it is move auction.cgi (and the rest of the cgi files) from

[mydomain.com...]

to

[mydomain.com...]

and everything will work? Perhaps you may also need to change $config{'cgi-path'} to include the extra directory.

If that is not it, and you are still having problems, I don't think there is any problem with stating the name of the software, as long as you don't provide a url to it. Others might have had experience setting up the same software.

Shawn

Ginaj

3:25 pm on Apr 25, 2003 (gmt 0)

10+ Year Member



Hi Shawn
I tried that too. But then the script put in:
/cgi-bin/mydomain/mydomain/auction/auction.cgi

I have just run envhtml.cgi and this is what I got when I ran this script and I think this is also wrong.
[SCRIPT_NAME] /cgi-bin/mydomain/envhtml.cgi
There is no "mydomain" directory in the cgi-bin.
I emailed the author of the script and he said everything looked to be set properly. This is why I am now thinking it is a server problem.

Matt: what is suexec? Is there someway I can check this out?

ShawnR

10:26 am on Apr 26, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Any luck yet? My understanding is that suexec is part of Apache, and allows an ISP to have one Apache installation, but with cgi programs executed under different User IDs (one for each of the domains they host). It is possible that this is what is causing the problem. Someone with more knowledge on this (or possibly the support team at your ISP) might be able to shed light. One obvious work-around would be to change all the

$ENV{'SCRIPT_NAME'}

in your cgi perl scripts to 'cgi-bin/<filename.cgi>'. A combination of other entries in the %ENV hash, or some of your script's configuration variables, might be used to do this.

On the one hand this might sound like a brute-force hack, and I am sure that if you reported the problem as a bug to your script's developer he would say "the script is fine, the ISP haven't configured the server properly". On the other hand, this might be a reasonable configuration, and the script might not be tolerant enough to cater for different server configurations.

Shawn

Ginaj

1:52 pm on Apr 26, 2003 (gmt 0)

10+ Year Member



Hi Shawn
Yes that did work. There are about 15 scripts involved, so I changed them all and that solved that problem, but now the posting of the forms in the script is not working, I keep getting a SCGWrap error. I am about to give up on this script.

mat

2:02 pm on Apr 26, 2003 (gmt 0)

10+ Year Member



I'm absolutely no expert here, but if you're getting CGI wrap errors then this is almost certainly an issue with the configuration of your virtual server and the path to your cgi-bin.

Does your webhost not have any instructions on running perl/cgi scripts on their servers? I really think you're coming at this the wrong way trying to bend the script to work - it will turn out to be a path/calling issue.

Just do a Google search on 'suexec and cgiwrap' and you'll learn all about the various ways of calling scripts on Apache. Again, I'd be very surprised if their isn't something on your host's help or FAQ pages. Again, this is a server, not a script issue. Talk to your hosts.

ShawnR

2:24 pm on Apr 26, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Mat's probably right. The brute force hack method is probably not the way to go...