CGI source code being served to the client instead of being executed.

[#1]

My CGI space has just been "migrated".
I had the permissions issue overnight, so I waited it out.
Now, the URLs to my CGI scripts are serving the script source code instead of executing it. As my CGI scripts are (proprietary) python code, it won't take someone long to follow the "import" tree to grab a copy of everything and then use the source code work out how to grab chunks of the database 
My area seems to have a "cgi-bin" directory (which is empty) and a "public/CGI-BIN" which appears to contain my original scripts (an example URL of "http://domain/cgi-bin/foo.py" will now serve the file "public/CGI-BIN/foo.py" to the client browser.
So, is there a config file or something I have to change somewhere that wasn't required on the old platform? Is that new directory hierarchy correct?

As a secondary thing, I generally use relatively little of the space available to me and so "File Manager Pro" indicates the following usage stats at the top: "(Disk Space: Total: 500  MB Used: 464.07 KB  Free: 36  MB)". Presumably that is just a coding error in the report and I really have 499.5MB remaining ...?

[#2]

Quote from: kdl

Now, the URLs to my CGI scripts are serving the script source code instead of executing it. As my CGI scripts are (proprietary) python code, it won't take someone long to follow the "import" tree to grab a copy of everything and then use the source code work out how to grab chunks of the database

That should have been sorted this afternoon. Let me look into it further.

Quote from: kdl

My area seems to have a "cgi-bin" directory (which is empty) and a "public/CGI-BIN" which appears to contain my original scripts (an example URL of "http://domain/cgi-bin/foo.py" will now serve the file "public/CGI-BIN/foo.py" to the client browser.

This is to get around the fact that PHP could be executed from the cgi-bin on the old platform but not the new. There's an .htaccess file in the root that's managing this redirection. If there's no PHP content in your cgi-bin then you could try copying the data to the cgi-bin in the root and commenting out/renaming the .htaccess file?

Quote from: kdl

As a secondary thing, I generally use relatively little of the space available to me and so "File Manager Pro" indicates the following usage stats at the top: "(Disk Space: Total: 500  MB Used: 464.07 KB  Free: 36  MB)". Presumably that is just a coding error in the report and I really have 499.5MB remaining ...?

Yep, that's a known issue. Doesn't affect everybody's account strangely enough

[#3]

Quote from: Bob

Quote from: kdl Now, the URLs to my CGI scripts are serving the script source code instead of executing it. As my CGI scripts are (proprietary) python code, it won't take someone long to follow the "import" tree to grab a copy of everything and then use the source code work out how to grab chunks of the database  That should have been sorted this afternoon. Let me look into it further.

Have a look at the .htaccess in your root. I've added Python as a handler now so Python scripts in the cgi-bin should now execute too. Those outside of it won't though without further fiddling. I'm going to ensure Python is added as a handler for other customer's cgi-bin's too.

[#4]

Quote from: Bob

Have a look at the .htaccess in your root. I've added Python as a handler now so Python scripts in the cgi-bin should now execute too. Those outside of it won't though without further fiddling. I'm going to ensure Python is added as a handler for other customer's cgi-bin's too.

OK, things are now being executed - thanks Rob.
However - Python version 2.2.1 ... 
Wow - that has its 12th birthday this April! It's definitely an older version than was on the previous server, so this might cause others problems too (my scripts have stopped working as generators are not supported in that version).
I can probably work around my immediate problem (fortunately, 2.2.1 can import generators from '__future__') but there would be major benefits in having a (2.x) version of Python that's less than a decade old available ;). Is that something you can raise as a request to Hostopia? I can understand if they didn't want to install something that got used as the default interpreter, but it would be very useful even if we have to explicitly request an alternative version with "#!/usr/bin/python2_7" or whatever in our scripts. Different Python versions can happily co-exist on one server (the libraries are installed side-by-side and the interpreter knows where to fetch its correct libraries from).
Thanks, Kevin.

[#5]

Quote from: kdl

Is that something you can raise as a request to Hostopia?

I'll do just that Kevin, although I can't guarantee anything. Whilst PHP/SQL etc. is very recent, there are a few areas of the environment that, despite being secure/safe etc. are a significant number of revisions behind.

[#6]

Was there any reply from Hostopia on a more up-to-date version of Python?
Thanks,
Alan

[#7]

Not sure if I ever received a response Alan. I'll chase it up again...

[#8]

Hi Alan,
I've had confirmation that Python should be updated to version 2.7.3 over the coming days. IIRC that's a fair few revisions beyond what was installed on the Plusnet platform.

[#9]

Bob - v2.7.3  will be more than good enough. Thanks for sorting it out
Alan

[#10]

A little bird tells me we should be running 2.7.3 now if you can spare a minute or two to check?

[#11]

Appears to still be v2.2, specifically:
2.2.1 (#1, Feb 3 2005, 15:45:36) [GCC 3.2.2]

[#12]

So it is, leave it with me...

[#13]

Change the shebang in your scripts to :

#!/usr/local/bin/python

[#14]

That works  - thanks for sorting it out