Can't make a Python script executable

[TeraBitByter]

Thanks for having a look at my plea for help. This is on a new installation of CentOS 4.2 (the single CD server install). I have the following Python script:

#! /usr/bin/python
#
print "Hello World"

called test.py located at /var/ww/cgi-bin.

I get the following results from an ssh session:

[root@localhost cgi-bin]# chmod +x test.py
[root@localhost cgi-bin]# test
[root@localhost cgi-bin]# test
[root@localhost cgi-bin]# test
[root@localhost cgi-bin]# test
[root@localhost cgi-bin]# python test.py
Hello World
[root@localhost cgi-bin]# /usr/bin/python test.py
Hello World
[root@localhost cgi-bin]# test.py
-bash: test.py: command not found

So when I enter 'python test.py' or ;/usr/bin/python test.py' I get the expected output. However, when I just enter 'test' I get don't get any output or any errors. From what I have read having "#! /usr/bin/python" as the first line in my script and running chmod +x on it should make it executable, so I don't understand why I don't see any output.

Is my output going some place else or is there something else I need to do to make a Python script executable?

Thank you for your help,

Tera

[angustia]

[root@localhost cgi-bin]# test.py
-bash: test.py: command not found


look at this.
the first word in a command must be the executable.
do you know how bash looks for executables?

[truls]

The current path (.) is not in the default search path for an executable.
If you want to run a program in the current directory, prepend ./ to the name.
In other words:
#./test.py
And you really shouldn't run everything as root. Especially not when trying out new things.

[TeraBitByter]

look at this.
the first word in a command must be the executable.
do you know how bash looks for executables?

I don't even know what bash is, so no, I have no idea how it looks for executables.

[TeraBitByter]

The current path (.) is not in the default search path for an executable.
If you want to run a program in the current directory, prepend ./ to the name.
In other words:
#./test.py
And you really shouldn't run everything as root. Especially not when trying out new things.

Thank you! Running './test.py' worked. Now I just need to figure out why I get an error from Apache when trying to access the script from another machine via:

http://<local ip address>/cgi-bin/test.py

the error being:


Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


I am curious as to why I shouldn't be running things as root?

[je_fro]

I am curious as to why I shouldn't be running things as root?
several reasons...in this case, what if the script did something unexpected? like remove all your device files? I'd NEVER run a script called test.anything as root.

[bwkaz]

Now I just need to figure out why I get an error from Apache Well, let's look at the error a second. ;)

Internal Server Error

<...>

More information about this error may be available in the server error log. You should check your server's error log. Generally this is something like /var/log/apache/error_log, but it depends on how your installation of Apache is configured. There's probably some better information in there.

As for not running stuff as root; you shouldn't run stuff as root for the exact same reason you shouldn't run Windows as a member of the Administrators group. (Unless you need admin access, for instance when you're installing something.) If you do that, then any code running as you has full, unmitigated access to the entire system, and can destroy quite a lot of things quite easily. (OTOH, in Windows, even running as a non-administrator doesn't completely lock you out of everything that's dangerous. But it's leaps and bounds better than doing your everyday work as a local admin.)

[TeraBitByter]

Well, let's look at the error a second. ;)

You should check your server's error log. Generally this is something like /var/log/apache/error_log, but it depends on how your installation of Apache is configured. There's probably some better information in there.

Thanks! After updating my script to spit out:

<html>
<body>
Hello World!
</body>
</html>

the error in the server log is:

[Sun Mar 12 13:11:34 2006] [error] [client <IP Address>] malformed header from script. Bad header=<html>: test.py

Which doesn't really make sense to me since the same html content works when I manually put it into index.html. Looks like I need to look into CGI scripting more to see what it requires to be included in the output to be considered valid HTML.


As for not running stuff as root; you shouldn't run stuff as root for the exact same reason you shouldn't run Windows as a member of the Administrators group. (Unless you need admin access, for instance when you're installing something.) If you do that, then any code running as you has full, unmitigated access to the entire system, and can destroy quite a lot of things quite easily. (OTOH, in Windows, even running as a non-administrator doesn't completely lock you out of everything that's dangerous. But it's leaps and bounds better than doing your everyday work as a local admin.)

Noted. I'll have look into how to configure Linux accounts then, although admittedly it's some what low on my list at the moment as this machines sole purpose is to be a local test server (it's behind a firewall without any ports open), and I don't have root access to the real server which is administered by the web host I'm looking into getting service from (but they can't tell me what version of Python they are running, so I need to get a script setup that will render it to a web page and then get a test account with them to find out).

[bwkaz]

the error in the server log is:

[Sun Mar 12 13:11:34 2006] [error] [client <IP Address>] malformed header from script. Bad header=<html>: test.py CGI scripts need to print out HTTP headers before printing out the HTML that they want to send to the client. Many CGI languages have functions you can call that do this for you. At minimum, you'll need a Content-Type header; you'll probably also need a Content-Length, and perhaps a couple others.

Which doesn't really make sense to me since the same html content works when I manually put it into index.html. In that case, Apache generates the Content-Type and Content-Length headers, and sends them itself. But it can't do that with CGI scripts.

as this machines sole purpose is to be a local test server (it's behind a firewall without any ports open), Well, there are reasons not to use root other than just security. You also can't screw anything up permanently if you run as a local user. (This is why viruses, etc. on Linux are never going to be a problem: There's no difference between a virus deleting all your files, and you doing an "rm -rf /" as root. And the solution to both is the same: Be paranoid about what you do as root.)

[TeraBitByter]

CGI scripts need to print out HTTP headers before printing out the HTML that they want to send to the client. Many CGI languages have functions you can call that do this for you. At minimum, you'll need a Content-Type header; you'll probably also need a Content-Length, and perhaps a couple others.

In that case, Apache generates the Content-Type and Content-Length headers, and sends them itself. But it can't do that with CGI scripts.

Well, there are reasons not to use root other than just security. You also can't screw anything up permanently if you run as a local user. (This is why viruses, etc. on Linux are never going to be a problem: There's no difference between a virus deleting all your files, and you doing an "rm -rf /" as root. And the solution to both is the same: Be paranoid about what you do as root.)

Thanks! Adding a Content-Type header was enough to get the expected result. I had no idea those headers were automatically added by webservers (all that I've worked with apparently). No wonder I didn't know they were missing!

That got everything running correctly on my local test server, but of course now it doesn't work on my real host. I can run it fine as a shell script via ssh, but when I access it in cgi-bin over the web, all I get is the source for script (i.e. it's treated as a text file rather then a script), so it isn't even attempting to run it. I did some searching and it seemed like adding "AddHandler cgi-script .py" to httpd.conf (via DirectAdmin actually, which I confirmed by viewing my local httpd.conf in VI) would do the trick, but it didn't. I figure my host must have something rather specifically configured on their server (I installed the same version of the OS they have on my local test server, CentOS 4.2), so I'll probably just have to wait to hear back from technical support to get this resolved.

Thanks,

Tera

[bwkaz]

Yes, if you add the AddHandler in your local .htaccess file, that may very well not take effect. AddHandler may only be allowed at the root level, which (if that's true) means your admins would have to enable it for you.

Alternately, you could name the script <something>.cgi, and leave the #!/bin/env python at the start of it. This might be enough to get it to work.