[Tutor] Re: Help with 500 error on cgi script

Mon, 19 Mar 2001 14:48:29 -0500

Did you actually type "username"? ;-).  I don't really know what that 
error means.  Usually for me it works, or it says bad password.  Maybe
they built a special version of su that doesn't allow users like you
to use it?

| ...<snipped>...
| :| Python 2.0 (#1, Jan 15 2001, 01:09:04) 
| :| [GCC 2.7.2.3] on linux2
| :       ^^^^^
| :Heh, that's a bit old.  I have heard (but not tried it for myself)
| :that g++ 2.7.x had a problem with calling dtors before calling copy
| :ctors when returning objects from functions.  Just FYI in case you
| :decide you want to play with C++ on that system.  That C compiler
| :should be ok since C is older and the compiler more mature.
| 
| Are you saying, that maybe I should uninstall my Python-2.0 and then
| re-install it using the C compiler instead of GCC? You think that might help?
| <sigh--sounds like a weekend project> I used gcc because that is what I'm
| familiar with. I don't know how to use the c compilers.

GCC used to stand for "GNU C Compiler".  It now stands for "GNU
Compiler Collection" and includes a C, C++, Fortran77, ObjC, Chill,
and Java compilers.  By default running 'gcc' gives you a C compiler.
Running g++ gives you C++ and gcj gives you Java.  By "The C Compiler"
I simply meant the C portion of gcc.  I was just mentioning that if
you plan on trying some of your C++ on the system, I have heard that
the C++ compiler portion of GCC 2.7.2 doesn't work.  I haven't heard
any complaints about the C compiler portion of it.

Python is implemented in C, not C++, so you shouldn't have any trouble
with gcc 2.7.2.

| Here is the output, calling it as a cgi-script:
| 
| -----------------------------------------------
| 2.0 (#1, Jan 15 2001, 01:09:04) 
| [GCC 2.7.2.3]
| -----------------------------------------------

got the right interpreter.

| OK, I beefed it up a bit, to find out what the actual paths are, when I run a
| script. I changed the script to this:
| 
| -----------------------------------------------
| #! /big/dom/xthinkspot/Python-2.0/python
| 
| import sys
| print "Content-type: text/plain\n\n"
| 
| print sys.version
| 
| print
| print
| 
| for path in sys.path:
| 	print path
| 
| print
| print "Those are the paths"
| -----------------------------------------------
| 
| Here is the output:
| 
| -----------------------------------------------
| 2.0 (#1, Jan 15 2001, 01:09:04) 
| [GCC 2.7.2.3]
| 
| /usr/local/lib/python2.0/
| /usr/local/lib/python2.0/plat-linux2
| /usr/local/lib/python2.0/lib-tk
| /usr/local/lib/lib-dynload
| 
| Those are the paths
| -----------------------------------------------

Those paths don't even exist, do they? 

| So, it is apparently not running my local copy of 2.0 at all??? These are not
| the paths to my install.

It is running your local copy, but the paths to the system libraries
don't match.

I just found sys.executable.  Here:

>>> print sys.executable
/usr/local/bin/python
>>>

| Hmm. Well, I will try what you suggest, and try manipulating the sys.paths and
| see if that will help. I'm feeling a bit hopeful, but I'm cautious of getting
| too hopeful, and be discouraged yet again.

Now we know the correct paths to use (the output from your interactive
run) you can just use those to make this script work.

import sys
sys.exec_prefix="/big/dom/xthinkspot/Python-2.0/Lib"

# now the rest of your script

If that doesn't work, then

import sys
sys.path = \
    [
        "" , 
        "/big/dom/xthinkspot/Python-2.0/Lib" ,
        "/big/dom/xthinkspot/Python-2.0/Lib/plat-linux2" ,
        "/big/dom/xthinkspot/Python-2.0/Lib/lib-tk" ,
        "/big/dom/xthinkspot/Python-2.0/Modules"
    ]
# now the rest of your script

should work.  Since none of the paths in sys.path were correct I am
simply assigning the correct version to it here, instead of just
inserting the extra path you want.

The thing I wonder now is why does it find the right path when you run
it interactively, but not as a cgi script.  Perhaps you did something
(like set PYTHONPATH, or maybe just PATH) in your login scripts that
makes it work from a login.

I would recommend following Arcege's suggestion of rebuilding the
interpreter using the proper arguments to configure so that the
correct default paths are hard-coded in to the interpreter.  For now
the quick hack of setting sys.path should work ok until you get time
to rebuild the interpreter.  If I recall, you mentioned having to pay
extra for the extra disk space your interpreter uses on the system.
Those tricks to cut down on disk usage would help.  Also, you can
remove each script in the standard library once you have imported them
at least once since the .pyc file is all you really need.  (but don't
remove the .py file if the .pyc isn't there ;-))

| :Since you got your python script to run fine on your windows system at
| :home you can certainly get apache set up on the school's systems.
| :Once you have that done it shouldn't be any trouble for the students
| :to write the scripts/apps. 
| 
| Well, thanks for the tips. I know I have at least one student who is very
| intersted in cgi and web programming in general, which is why I'm even
| entertaining the notion of trying this. 

Perhaps it would be advantageous to set up a Debian box to be a server
for the students?  Then you would only have 1 system to set up with
apache, etc and students could use remote login to work with it.
Although, if they only know how to use MSVC++ and Windows Explorer it
would probably be more of a pain for them than it is worth.  Unless
they are really interested in *nix and want to learn it, of course.

I develop using bash+(g)vim+(print|cout|printf|System.out.print) most
of the time.  Sometimes I actually use a real debugger too ;-).

-D