|
I've been using the Internet since 1993. I opened my first Web site in 1998. I've taught myself HTML, CGI, Perl and SQL. I am *not* an expert by any means. However, I have written Perl scripts to solve problems for myself, my clients and my friends. I hope that much of what I've learned will help you to master the art of writing, installing and using CGI scripts more easily (and faster) than I did. |
|
This book is intended to teach you how to obtain (or write) and install CGI scripts written in Perl or other programming languages. The focus is mainly on scripting in Perl, but the installation process is very much the same for CGI scripts written in any other language. By providing you with some complete scripts, some subroutines and the tools for combining them in new ways, I hope to teach you a "mix-and-match" approach to solving scripting tasks. I believe that if you follow the principles taught here, you can be installing CGI scripts on your Web server/site in a very short time. Friends, this is not rocket science! It's simply a skill you have not yet acquired. There was a time (come on...admit it) when you didn't even know how to "surf the Web". You mastered that easily enough, didn't you? You can pick this up almost as easily. Once you've got it, you'll see that it really wasn't all that hard. |
|
First, you will learn what CGI is, what a script is and how it works. Then, you will learn about subroutines and how they can be re-used to save lots of time and effort. You'll discover where to find free CGI scripts and how to get them. You'll find out how to take a useful subroutine from one script and use it in another script. By applying what you've learned, you'll be able to create whole new scripts "out of thin air" by putting together pieces you found here and elsewhere. You'll discover how CGI can make your Web site more interactive and how to make it perform repetitive tasks automatically. Your Web site should be able to work for you like a tireless employee. Your knowledge of CGI scripts will make this possible. You will learn how to install a script on your Web server. We will cover using ftp to get the script into the right place, setting file permissions so the script can be run and connecting it to your Web pages. You will see how to tell whether the script is working properly and how to fix the most common problems that keep it from behaving as intended. You will learn how to collect the email addresses of your visitors, add them to your mailing list and follow up with sales letters or other information. By doing this, you'll be able find new prospects and turn them into paying customers. You'll learn how to take payments and give receipts - online and by email. You'll see how to do any math you need to do and how to display properly formatted dollar amounts. Users of other currencies may need to modify these routines somewhat, but the principles will still apply. You'll learn how to save data you collect in a database and extract usable information from that data. You will learn how to deliver error pages, thank-you pages and totally customized pages that are unique to each visitor during their stay at your Web site. |
What this book is NOT |
This book is not an exhaustive reference for programming in Perl. If you want to all about Perl, you'll need to get one or more of the excellent books available on the subject. Some of these are listed in Appendix A. For more guidance, visit the Perl home page: This book is also not a complete guide to installing scripts on every possible type and configuration of Web server and/or hosting company. That would require years of research and would fill many hundreds of pages. Not only that, but it would need to be updated constantly. There are many "quirks" associated with different servers which can make installing a script more challenging. The basic principles are discussed here. For most users, this will be enough to enable you to install your own scripts. If you are unable to get a script installed, it is usually best to talk to the system administrator or the technical support personnel at your Web hosting company. Many problems like this can be avoided if you carefully follow the instructions and procedures given here. In rare cases, it may be necessary to have a professional install your script. A few reputable installers are listed in Appendix B. |
|
I'm pretty sure you're going to skip around in this book, at least at first. So, there are several places where topics are repeated, discussed in more detail or you're referred back to another chapter. This is your book now; use it to your best advantage. Bounce around, read it straight through or whatever works best for you. I've tried to make it as easy as possible for all types of readers. First, read Chapters 2, 3 and 5. This will give you a good understanding of what CGI is and help you determine whether you can use it on your Web site. If you find that there is problem with your host which will prevent you from using CGI, seriously consider changing to a different host. Many free sites, as well as some very low-priced hosts, will not let you run your own CGI scripts. If this is the case, please refer to Appendix B for some hosting companies that will give you more power and flexibility. Keep in mind that the some scripts are going to be difficult to install if your host does not allow you enough control. If you did not find any of the limitations mentioned in the last paragraph, that's great! Now, read Chapter 6 to get a grasp of what's involved in installing scripts. As you go through this crucial area, I'll guide you every step of the way. Great care has been taken to present the tools and concepts in a logical order. If you find that you are sufficiently familiar with the contents of a section, feel free to skip ahead. I do suggest that you do everything in the order I've presented it, because you'll encounter far less trouble that way. Now decide what task you want to accomplish with a script. If what you want can be done by one of the complete scripts provided here, you are in luck. See the next paragraph; it will tell you how to pull out that script and get started. For any of the complete scripts, simply copy and paste all the code into a new text file. Save it with a name of your choice and a .pl or .cgi extension. I use WordPad for this purpose, but any text editor will do. Don't use a word processor (such as Microsoft Word, for example). Word processors insert invisible (non-printing) characters for formatting which will corrupt your script. If you didn't see a script that does exactly what you want among the ones included here - don't worry. There are loads of CGI scripts free for the taking on a number of Web sites. Chapter 4 will show you a lot of places to shop for free scripts. Some will also have scripts for sale. In a few cases, you'll come across a script (usually a very complex one) that requires a monthly or yearly payment for using it. Often, such scripts reside on the owner's server, and you merely call them with a few lines of your own code. My advice is simple: If you can find a free script that does the job...use it. If not, consider putting together a script of your own. I'll show you how to do that. You can use one or more of the subroutines included here to build a new script or add features to an existing one. If you aren't comfortable with the job of composing a new script, search around for a paid one that meets your needs and buy it. For subroutines, copy and paste them into some existing script or a new one you are starting. Be absolutely sure that you get the closing "}" character of the subroutine, or they won't work! If you buy a script, you can install it yourself in most cases. Take your time, read all the instructions and do exactly what they say. You may have to edit a line here and there to customize the script. After you've read Chapters 6 and 7, you'll see that this is really pretty easy. If you are going to write (or at least piece together) some scripts of your own, you'll want to read Chapters 8 through 17. Feel free to skip any sections that you don't need for your current project. You can come back later when you need to learn what they can teach you. If you stop at Chapter 7 and come back later, be sure to at least skim Chapter 7 and review the mechanics of writing a script. As with many skills, you may have forgotten something if you haven't used it for a while. There will be times when you just want to modify an existing script. Perhaps you want to add a feature or change the way something works. In Chapter 12, you'll discover how to work with subroutines. This comes in handy for adding one or more features to an existing script. You can often find a subroutine that provides just the feature you want to add. Here's an example: Let's say you found a really useful free script that uses sendmail to compose and send email messages. If you're on a Unix host, it will probably work just fine. Almost every Unix host has the sendmail program installed. However, if your site is on a server that runs Windows NT, the script cannot work. Why? Because sendmail is a Unix program! Most NT hosts have a mail server program called iMail. The current version is 6.05. Here's a case for modifying a script. See Chapter 14 for advice on how to convert the script to use iMail. The reverse case is also covered. By the way, the documentation of a great many scripts says the script will not run on NT. Quite often the problem is simply that the script expected to find sendmail or qmail. Replace the mail-handling subroutine with one from here that works with iMail. If the server is using iMail, your script may work now! If not, there may be other differences to work out. |
|
Server - a computer that runs programs for its clients. A Web server, for example, runs mail programs, delivers Web pages, maintains Domain Name Services, etc. Client - a user's computer, such as your own PC, Mac, etc., which requests files or services from a server. Client also refers to the programs you run which need services from another computer or a program running on another computer (a server). For example, your Web browser or FTP program is a "client" which requests and (usually) gets services from another computer and/or program. When you visit a Web page, your browser (the client) asks a Web host (which is running Web server software) to send you a file (an HTML document or other file). In any networked environment, such as the Internet, there are a number of servers and a much larger number of clients. Similarly, if you have a telnet (client) program, you can log in to a remote computer's telnet (server) program and operate that computer from your own keyboard and monitor. Unix - a multi-user, multi-tasking operating system for computers made by Sun, DEC, IBM and others. Multi-user means that many users (people) with separate work-stations (computers connected in a network) can use the servers (computers which hold application programs, shared files, etc.) together at the same time. Multi-tasking means that many programs can be run at the same time. The majority of Web hosts (servers) are using the Unix operating system. There are many versions or dialects of Unix, including Solaris and the wildly popular Linux (which comes in many varieties including Red Hat, Slackware, Debian and others). In this book, Unix may be taken to mean the same as Linux for all practical purposes. A typical modern Web server (computer) will have the Linux operating system and the Apache Web server (software to manage Web sites). Another popular server configuration is Windows NT (operating system from Microsoft) with a Web server (software package) such as WebSite. CGI (Common Gateway Interface), is simply a way of exchanging data between your browser and a program running on a Web server. It is made up of a set of standardized variables used to pass specific types of data between a client and a server. (Now you see why I wanted you to know the terms "client" and "server".) FTP (File Transfer Protocol), is a way to send documents or files from one computer to another using the Internet. An FTP program, or client, is the program you use to send (upload) or receive (download) files to or from a computer (server) connected to the Internet. When you send Web pages to your site, you are using ftp, whether you start an FTP program or use a control panel on your Web host. Telnet - a client program that lets you use a remote computer. Once logged in, you can run programs, list directory contents, set file permissions (Unix systems), etc., as if you were actually at the console of the remote machine. Program - a set of instructions that tell a computer how to do something. Since the instructions don't usually change from one execution to another, a program generally does exactly the same thing every time it runs. If a program's outward actions are directed by data given to the program when it starts, the visible output will be different for different inputs. Script - often referred to as a program, a script is actually a little different. Sure, it acts just like a program. It follows the description I just gave you for a program, but the difference is in how it runs. A program is ready to run immediately (its instructions are in machine code) but a script is interpreted line by line. There is a command processor or shell program on the server that figures out what each line means and then runs it. For Perl scripts, this processor is the Perl interpreter. Its name is perl.exe, and it is a program by the first definition. |
|
This is a big topic, and I'm only going to give you a brief description. In general, data of some kind is passed to a CGI program or script. Taking the classic example of filling in a form on a Web site, the form is the first link in the chain of events. Data items are typed into the form by a user. Then the user clicks on the button that "activates" the form. A script is called, which takes data given to it by the form. It then decides what actions to perform on or with the data. Finally, it produces some output. This output can be in the form of sending an email message, delivering a customized (or stock) Web page or perhaps reading from/writing to a database. The form (client) has requested the services of the script (server), which does its thing and sends the result back to the client (browser, mail program, database, etc.) CGI programs run on the Web server. Because of this, your visitors can use any browser they like. Other types of Web programming such as JavaScript, actually run on your visitor's computer. If the user has an older browser which can't run JavaScript, your efforts are wasted on them. Likewise, if they have a browser than can run JavaScript but have disabled it in their preferences, they won't see the whiz-bang interactive features you worked so hard to implement. About the only downside to all this is that running CGI programs make your Web server do the work. But I just said that was good, didn't I? There is a cost to everything, and CGI is no exception. If your server is under-powered or overloaded, it may slow down as a result of running your CGI programs. |
|
Many different languages can be used for CGI. Perl, Python, ASP, C++ and Java are a few that have become popular. PHP is gaining ground, especially where high-performance programs are needed. The rule is basically that any program that can be compiled and run on your server can be a CGI program. Interpreted languages such as Perl and Python can even be compiled into an executable form. However, they are most often left as scripts to be interpreted by the server's command processor. Most of the database programs in use today can be controlled by statements in a standardized language called SQL (Structured Query Language). Programs and scripts can send SQL commands to a database server program running on a host computer. Methods of preparing and sending the commands may vary, but the commands themselves are nearly universal. You'll see examples of how a Perl program can send commands (or queries, as they are usually called) to a database server later in this book. |
|
You can write and run scripts or programs that make your Web site more "interactive". In other words, you can use it to make a Web page actually do something. Typical CGI programs do things like gather information from a form, send email messages or read from/write to a database. They can be used to automate all sorts of processes like subscribing people to your newsletter, taking payments for products and/or services that you sell and so on. Remember that you'll need some type of payment processor such as a merchant account, ClickBank, etc., to actually get the money and send it to you. |
|
PERL - Practical Extraction and Reporting Language; Perl is an interpreted language (like BASIC from the Dark Ages of computing). It is handled by a command processor which determines the meaning of each line as it reads the script. Despite being processed by this other software before actually running, Perl is very fast. Perl used to be known as "the language of the Internet". This is not as true as it once was, but Perl is still extremely popular. Reasons for this include its power, speed and ease of use. Aside from the many odd-looking operators, it is easy to read a Perl script if you have any experience with a structured programming language such as Pascal, C or C++. |
|
As I just mentioned, Perl is fast, easy and relatively simple. Its string-handling capabilities make it a great choice for processing information from forms, producing customized Web pages and much more. It can do math operations, talk to databases, manage lists of items and many other tasks using very little code. Since it supports subroutines, you can reuse blocks of code from earlier scripts in a new script. See Chapter 12: Using Subroutines for more about this topic. A third good reason is availability. Almost every Web server in existence has a copy of the Perl interpreter installed. This is partly because it's free. Perl is supported, maintained and improved by a community of users and programmers. It is made available under the GNU General Public License. Server administrators don't have to buy Perl and keep paying for every upgrade. That's a great incentive to keep a current version of Perl on their computers. Another reason to program in Perl is that it's pretty easy to learn. You can pick up the basics in a few hours and learn more advanced elements as the need arises. You can go to the Perl home page and search for a topic that interests you. Chances are good that a script or a module has already been written which you can use right now. Within minutes, you can be reading the code of a script that does some or all of what you need for your current project. If it can be used "as is", just download it and use it. Or, if some part of it solves a small problem in a larger project, grab the that part of the code, paste it into your script and make whatever adjustments may be needed. Often it's just a matter of matching a few variable names so the new code fits right in with yours. |
|
For best results in all situations, I suggest using the most recent version you can get. Currently, version 5.004 or higher is available on most systems. This version will support practically anything you can ask a Perl script to do. The most recent version can always be found at the Perl home page: |
|
Get your hands on one or more books about Perl. Even if you never write a script, it's good to know how it works. That will help you decide if a free script you're considering will do what you want, the way you want it done. There are several good ones listed in Appendix A. These and others can be bought at bookstores like Barnes & Noble, BookStar, Books-A-Million and Borders. Feel free to shop the online stores as well; you may find a bargain at Amazon.com or bn.com that beats the store price. Don't overlook used-book stores either! For those on a very tight budget, borrow them from a library or a friend. Technical Community Colleges, state Universities, etc., have vast libraries with lots of this kind of stuff. Read a book about Perl programming and work through the examples. Get familiar with "reading" and understanding how the various parts of a Perl script work. Next, download some completely unfamiliar scripts and use what you've learned to figure out exactly how the script works. After you do that a few times, you'll be able to understand most of what you read. If you see something you don't understand, look it up in a Perl manual. Typically, the most confusing parts are the strange-looking "operators". So, start with a cryptic statement like this: /^[\w\d][\w\d\,\.\-]*\@([\w\d\-]+\.)+([a-zA-Z]{3})$/ Find a list of operators in the book and see
which of the symbols in the line you're reading are operators. Replace them with
plain English words that mean the same thing as the operators. Keep replacing symbols
with words until you have a readable sentence. Now go back and look at that line
again. It has magically become readable to you!
|
|
By now, you have a good idea of what all this book will teach you and how that knowledge will make you money. Are you getting excited? You should be! With what you llearn, you'll automate all sorts of processes on your Web site and make better use of your time. That means you can spend more time making money. Naturally, you'll want to read the rest of the book. You've just got to see all the free bonuses that come with it, and the support features the author provides. So why not go find out how to get your own copy right now? Click Here Remember, the Internet is huge. It's easy to get lost and not find your way back to that special site or page... Follow the link now. Save time, earn more money, get out of the Rat Race! You deserve a better life, don't you? Get the tools to make it happen today. |