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

Sheila King sheila@thinkspot.net
Mon, 19 Mar 2001 12:37:31 -0800


f3hf-0005oE-00@mail.python.org> <20010319144829.A23716@harmony.cs.rit.edu>
In-Reply-To: <20010319144829.A23716@harmony.cs.rit.edu>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <FC65773FF8@kserver.org>

On Mon, 19 Mar 2001 14:48:29 -0500, D-Man <dsh8290@rit.edu>  wrote about Re:
[Tutor] Re: Help with 500 error on cgi script:

:On Mon, Mar 19, 2001 at 09:44:13AM -0800, Sheila King wrote:
:| On Mon, 19 Mar 2001 11:04:31 -0500, D-Man <dsh8290@rit.edu>  wrote about Re:
:| [Tutor] Re: Help with 500 error on cgi script:
:| :$ su username
:| :
:| :My previous environment remains (ie PATH, etc) but if I use
:| :
:| :$ su - username
:| :
:| :I get a new environment, the environment specified by that user's
:| :.bash_profile/.bashrc.
:| 
:| Either of these gives me the following error message:
:| while opening UTMP file: Permission denied
:| while opening UTMP file: Permission denied 
:
:Did you actually type "username"? ;-). 

Er, um, well, only the first time. But I did get the same error message, even
when I typed my *real* username, and the error messages above were generated
with the *real* 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?

Probably they won't allow users like me to use it.

:| 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? 

Nope. I tried to go there, and just got error messages.

: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.

Thanks. That's what I'm doing for now, and it seems to work, until I get a
chance to re-install.

:| :When you run the interpreter at an interactive shell prompt and import
:| :cgi, where does it find cgi?  Do this:
:| :
:| >>> import cgi
:| >>> print sys.modules["cgi"]
:| <module 'cgi' from '/big/dom/xthinkspot/Python-2.0/Lib/cgi.pyc'>
:| >>>   
:| 
:| :If we can figure out where (and how) it is getting 'cgi' interactively
:| :then it should be easier to find it when executed by apache.
:| 
:| Well, I feel like I have enough to try something else now. Thanks for the
:| help.
:
: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.

Yes, I did change my PATH variable in my .bash_profile file.

: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.

Will do.

:| 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 ;-).

Nooo, I don't think I will do anything with Debian (or other *nix). First off,
there is no machine available, nor is there space in the classroom for it.
Secondly, can you say: "28-stand alone, non-networked computer lab". (It is no
fun administrating such a lab, I can assure you.) Also, I only have about two
weeks for these projects, no one has expressed interest in other OS's (they
even seem surprised when I refer to MS as the "evil empire"--they do not "get
it"). In two weeks, teaching cgi scripts on an OS they are familiar with, in a
programming language they already know will be more than sufficient fun, I'm
sure.

We don't use MSVC++. We use MetroWerks CodeWarrior Pro 5.

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/