modules and may need to be converted to the server platform’s text file format after
being uploaded. Let’s look at each install constraint in more depth:
Directory and filename conventions
First, CGI scripts need to be placed in a directory that your web server recognizes
as a program directory, and they need to be given a name that your server recognizes
as a CGI script. In the local web server we’re using in this chapter, scripts need to
be placed in a special cgi-bin subdirectory and be named with a .py extension. On
the server used for this book’s second edition, CGI scripts instead were stored in
the user’s public_html directory just like HTML files, but they required a filename
ending in a .cgi, not a .py. Some servers may allow other suffixes and program
directories; this varies widely and can sometimes be configured per server or per
user.
Execution conventions
Because they must be executed by the web server on behalf of arbitrary users on
the Web, CGI script files may also need to be given executable file permissions to
mark them as programs and be made executable by others. Again, a shell command
chmod 0755 filename does the trick on most servers.
Under some servers, CGI scripts also need the special #! line at the top, to identify
the Python interpreter that runs the file’s code. The text after the #! in the first line
simply gives the directory path to the Python executable on your server machine.
See Chapter 3 for more details on this special first line, and be sure to check your
server’s conventions for more details on non-Unix platforms.
Some servers may expect this line, even outside Unix. Most of the CGI scripts in
this book include the #! line just in case they will ever be run on Unix-like platforms;
under our locally running web server on Windows, this first line is simply ignored
as a Python comment.
One subtlety worth noting: as we saw earlier in the book, the special first line in
executable text files can normally contain either a hardcoded path to the Python
interpreter (e.g., #!/usr/bin/python) or an invocation of the env program (e.g.,
#!/usr/bin/env python), which deduces where Python lives from environment var-
iable settings (i.e., your $PATH). The env trick is less useful in CGI scripts, though,
because their environment settings may be those of the user “nobody” (not your
own), as explained in the next paragraph.
Module search path configuration (optional)
Some HTTP servers may run CGI scripts with the username “nobody” for security
reasons (this limits the user’s access to the server machine). That’s why files you
publish on the Web must have special permission settings that make them acces-
sible to other users. It also means that some CGI scripts can’t rely on the Python
module search path to be configured in any particular way. As you’ve learned by
now, the module path is normally initialized from the user’s PYTHONPATH setting
and .pth files, plus defaults which normally include the current working directory.
Climbing the CGI Learning Curve| 1143