Perl Cd Bookshelf [Electronic resources] نسخه متنی

19.3.1. Problem

Follow the checklist given in the discussion.

This checklist is aimed at a Unix audience, but the general
principles embodied in the questions apply to all systems.

Check ownership and permissions with ls -l. The
appropriate read and execute bits must be set on the script before
the web server can run it. The script should be readable and
executable by everyone (or at least by whomever the server runs
scripts as). Use chmod 0755 scriptname if it's
owned by you, or otherwise chmod 0555 scriptname
if owned by the designated anonymous web user, assuming you are
running as that user or the superuser. All directories in the path
must also have their execute bit set (most FTP clients support
changing protections on uploaded files if you don't have shell access
to your server).

Make sure the script can be identified as a script by the web server.
Most web servers have a system-wide cgi-bin, and
all files in that directory will be run as scripts. Some servers
identify a CGI script as any file whose name ends in a particular
extension, such as .cgi or
.plx. Some servers have options to permit access
via the GET method alone, not through the POST method that your form
likely uses. Consult your web server documentation, configuration
files, webmaster, and (if all else fails) technical support.

If you're running on Unix, do you have the right path to the Perl
executable on the #! line? The
#! line must be the first line in the script; you
can't even have blank lines before the #! line.
Some operating systems have ridiculously short limits on the number
of characters that can be in this line, so you may need to make a
link (e.g., from /home/richh/perl to
/opt/installed/third-party/software/perl-5.004/bin/perl,
to pick a hypothetical, pathological example).

If you're running on Win32, have you associated your Perl scripts
with the correct Perl executable? Or, if your server uses
#! lines, have you given the correct path in the
#! line?

This prints the username the script is running as.

Identify the resources the script is trying to access. List files,
network connections, system calls, and so on, that require special
privilege. Then make sure they can be accessed by the user the script
is running as. Are there disk or network quotas? Do protections on
the file allow access? Are you trying to get the encrypted password
field using getpwent on a shadow password system
(since usually only the superuser can get shadow passwords)?

Set permissions on any files the script needs to write to at
0666, or better yet to 0644 if
they're owned by the effective user ID the script is running under.
If new files are to be created or old ones moved or removed, write
and execute permission on the enclosing directory of those files is
also needed.

The HTTP header must come before the text or image you return. Don't
forget the blank line between the header and body. Also, because
STDOUT is not automatically autoflushed but
STDERR is, if your script generates warnings or
errors to STDERR, the web server might see them
before it sees your HTTP header and can generate an error on some
servers. Add this at the top of your script (after the
#! line) to also flush STDOUT:

$| = 1;

Don't ever try to decode the incoming form data by parsing the
environment and standard input yourself. There are just too many
places where it can go wrong. Use the CGI module and spend your time
writing cool programs or reading slashdot instead of tracking down
bugs in your implementation of an arcane protocol.

Check the FAQs and other documents mentioned at the end of the
Introduction to this chapter. There is still a chance that you have
made a common mistake on whatever system you're using—read the
relevant FAQs to make sure you don't embarrass yourself by asking the
CGI equivalent of "why doesn't my car run when it's out of gas and
oil?"

Ask a friend. Almost everyone knows somebody they can ask for help.
You'll probably get a reply much sooner than if you asked the Net.

Post to comp.infosystems.www.authoring.misc if
your question is about a CGI script (the CGI module, decoding
cookies, finding out where the user is coming from, etc.).