Slashdot Mirror
CGI Programming with Perl
The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.
Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.
In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...
What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.
Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.
Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)
The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)
It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)
What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)
Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)
The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!
Table of Contents- Getting Started
- The Hypertext Transfer Protocol
- The Common Gateway Interface
- Forms and CGI
- CGI.pm
- HTML Templates
- JavaScript
- Security
- Sending Email
- Data Persistence
- Maintaining State
- Searching the Web Server
- Creating Graphics on the Fly
- Middleware and XML
- Debugging CGI Applications
- Guidelines for Better CGI Applications
- Effeciency and Optimization
- Works Cited and Further Reading
- Perl Modules
CGI programming with perl is fine, but remember that unlike with languages like java, you can't always take it with you. Going from sparc to x86 and vice versa has always been a headache.
I wouldn't have put CGI in the title if I were them. I'd call it something like 'Web Programming with Perl' in order to avoid the feeling that it's an outdated book. It doesn't seem to be, and CGI information isn't outdated, it's just that anything that says CGI _sounds_ old. Then again, maybe there's already a 'Web Programming with Perl'?
There is - it is called CGI. You can write CGIs in C, Perl, shell script, LISP or whatever you want.
BTW if you like ASP then try the Chili!Soft ASP add-on, or get Apache::ASP for ASP using Perl, or use the OpenASP module.
I say stick with mod_perl and HTML::Mason for best results.
The bulk of the new material came from Guelich and Birznieks. They credit Gundavaram for some updated material, but he apparently didn't provide enough to write a new author preface.
As for the examples, I've flipped through approximately half of the new edition, finding nothing that you described. The provided code is mostly short and sweet. The e-mail addresses used in the e-mail chapter examples are all fake, too.
As for the affiliate payments, no one ever tells me if anyone makes any money off of the referrals. I don't care, either. They send me 10 pounds of fresh bacon every month if I like the books or not. Don't just take my word for it, though, flip through the book at your local bookstore on your own. Not everyone looks for the same things I do.
--
how to invest, a novice's guide
If you mean Perl 5.6, the current stable version, the 3rd edition of Programming Perl covers it in abundant detail. Expect that review to be posted sometime in the next couple of weeks.
The 4th edition of the Camel will cover Perl 6, which is still in the design stages. Don't expect even a beta release for a year.
--
how to invest, a novice's guide
Besides, even if it did mention per 6, there'd not be a whole lot to it. Larry's still churning away on the language spec and, while we've started designing bits of the guts that aren't dependent on that design, the guts are nowhere near designed, let alone written.
Do not get the first edition! It was horrible. Form the review, it seems like they got the second edition right.
I'd say so. The main (and very big) fault of the first edition is the lack of CGI.pm coverage.
I can't believe you're actually recommending ASP in lieu of cgi/perl. If he wants to do a perl guestbook, chances are he's not on NT anyway. I really don't want to start a NT vs Unix thing but ASP???!? Gasp shock etc etc
Excluding language goals, both can be equally powerful server side programing languages. It really boils down to matter of personal taste if the programmer is sufficiently skilled. If you like PHP that's cool and nice but don't claim ASP is a better alternative!!! ICK ICK ICK
For most sites, plain old cgi works JUST fine. If the fellow wants to do a guestbook I'd say it's a personal low-traffic site, in which case perl/cgi works just fine. Proffesional sites should always be done in mod_perl.
While I do know what you are getting at, you should probably be more specfic. "the future of web programming" should probably be changed to "the future of professional web programming". It seems nit-picky but I never want to disuade hobbiest from making some neat interactivity on their site by forcing them to do mod_perl, CF, PHP or some other more complex method of server side programming.
Additionaly : ) CGI as a protocol is not outdated. It is inflexable, inefficent and some other adjectives but it still fills it's role nicely.
What's so exciting about a language neutral "Way" to run server side code? Are you by change refering to mod_asp or something? [insert personal attack here]
Does it use/mention Perl 6? Is there a good book covering Perl 6 yet? I've had the camel head book for awhile and like it, but haven't delved deeply into Perl yet. If the new features in 6 are worth learning, which book would you recommend? Or maybe someone could summarize the changes here, and I can decide for myself whether I want to look for a book.
Constitutionally Correct
$random = int(rand 10); # random number, 0-9
Alternatively, use the CPAN module Math::TrulyRandom
My usual reference text is 'Building Apache modules with Perl and C', but this book still has some tricks to teach even the experienced mod_perl developer
The mod_perl book doesn't cover http file upload in any way, and I'd been looking around for ages for a book that covered the topic. After reading the section in The Rat Book - File Uploads with CGI.pm (p.97) - I was able to quickly build my image upload facility.
Last time I looked, the guys at slashcode still hadn't worked out how to do this. Perhaps chromatic should donate his copy to pudge?!
The first half of the quarter we did not even look at cgi, it was all the standard hello_world programs in any introduction to /insert language/ programming class using the basic perl book.
The second half of the quarter we focused on implementing what we had learned about basic perl programming and using that for cgi.
I still have my cgi programming with perl (first edition) and open it every once in a while. The thing is that i use my perl black book (by coralis) more than any other book on perl programming.
If you want to learn perl for cgi, buy a basic perl book and study that.
Programming Perl is one of the better O'Reilly books ever written, IMHO, and that is saying a lot. If you want to use Perl, get it, Love it.
Frums
How are you doing, Merlyn? ;-)
--
At the same time, Perl itself has an unapolagetic unix flavor
This Wiki Feeds You TV and Anime - vidwiki.org
We took a perl webmail script running on Apache, Linux and stuck it on IIS, NT server (after installing Perl), and it worked. I daresay any perl program is about as portable as an equivalent java program.
And unlike Java, we don't need to upgrade to Perl 5.6.0 or whatever comes next because the basic Perl 5.0 functionality is already so high. In contrast, with Java 1.0, everybody really had to move to 1.1, and then they really want to move to 1.2 (aka Java 2). And many popular things (APIs, calls etc) were broken/incompatible each step of the way.
And those version problems with Java are even worse when you crazy enough to use applets. So much so that I think all that write once run anywhere is still bullshit. When people say "Ah but it's not like that for serverside", I tell them: Who needs portability with server-side? Plus almost any Unix stuff is just as portable to other Unix O/Ses as Java is, so what's the big deal.
BTW those that say C is more portable than Perl/Java etc between x86 and Unixes are probably hardworking folk who don't mind writing their own O/S from scratch, and who think that it's still considered portable because they only had to spend a week figuring out an undocumented O/S behaviour.
The reason why Perl and Java are portable is because of these hardworking folk porting perl/java to these O/Ses, providing the abstraction layer so that we don't have to do much other than copy our stuff over.
So Perl is about as portable as Java. Same goes for any decent scripting language (Tcl etc). As long as the hardworking folk port the VM/interpreter/compiler across, us lazy folk can copy our scripts over.
Don't be blinded by the Sun.
Cheerio,
Link.
I assume I already have the first edition of this book (one I highly recommend BTW) as I've had it around a year - but the question is, is it worth buying this edition (the second) if you already have the first?
Richy C.
--
that this book would replace taking a class on perl? My perl skills are weak and I am looking to strenghten them. Hell, I cant even use a cgi script to host my own guestbook.
www.droppingdimes.com
Although I mainly develop in Cold Fusion (mock me now, but my project will be done in 1/2 the time), the reality is that Perl (esp with mod_perl) is still one of the most robust scripting languages around. There are situations where scripts that incur heavy load the only good solution for me is Perl as it will run better than ASP,CF,JSP etc. I highly recommend not only this book, but also Programming Perl from Orielly (now in it's third edition). The combination of these two books will enable anyone with web development knowledge to kick out good Perl in a matter of days.
Of course, to be a REAL master, don't forget to purchase "Mastering Regular Expressions" from Orielly as well!
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
What was the point of the review. Everyone knows that the best books come from O'Reilly. What else is there to say? I personally own the Camel for Perl, I use it for all my reference needs. All that really needs to be said is: "there is a good book you don't have. the title is x. go buy it."
Don't make me use my other sig!!
This is interesting . Can i have more information on this ? I understood but maybe i'm wrong that mod_perl modifies some of the perl libraries.
Most annoyingly, he seemed obsessed with seeing his name in print, so that there were lots of examples - and I mean what seems like several dozen - where his name was gratuitously placed, such as
code with $webmaster="shishir\@bu\.edu", where $webmaster was never referenced later,
where his name was in <ADDRESS> tags, for no apparent reason, except that we get to see his name again,
etc.
At one point I entertained making a "shishir gundavaram sucks" page, detailing every single offence, it drove me so mad.
This book was the single worst O'Reilly book I have ever read, and if I hadn't bought so many good ones in the past, I would probably never so much as pick up another one.
I would be afraid that the addition of two more authors would just mean two more names repeated ad infinitum in every piece of example code. Aaargh! After 3 or 4 years, Just when this book got out from under my skin, there it is.
This post is insightful? Give me a break, this guy is totally ignorant, he collected some ideas from different sources, combined and posted here...
I read it and I recommend this book; quite easy to read. Don't expect it to teach you some breakthrough perl technique, it is only about web page programming using perl.. You need to have a good understanding of perl basics to make use of this book. I have been programming CGI for about a year and I already discovered most tricks in this book by myself.
Read Teach Yourself CGI Programming with PERL 5 in a Week online.
Free Anne Tomlinson!!
I would not reccomend Programming Perl for a beginner to Perl. Some of the info. in Programming Perl assumes not only that you have programmed before, but also that you are (somewhat) familiar with compiler internal basics. If you have programmed before or you are familiar with Unix tools such as grep/sed/awk (or if you are pretty smart), buy Learing Perl. Otherwise, take a class and ask the instructor which book to buy after the class. If Perl is confusing at first, don't sweat, it can be difficult for a beginner.
"C" is for cookie, that's good enough for me.
The previous edition had lots more on dealing with CGI without CGI.pm Fortunately, O'Reilly has been good enough to post the old version on the net (free):
CGI Programming on the World Wide Web - 1st ed.
A beginners' guide to Portland, OR?
l33t j03, posting anonymously because Taco has banned me.
If you're more of a do-it-yourself-er, pick languages up easily, and want a more complete Perl reference, get the Camel book (Programming Perl).
If you just want some scripts to copy, look on the web or get the Perl Cookbook.
And if you want to learn advanced Perl stuff, and enjoy extreme pain and an awkward writing style, get Advanced Perl Programming.
I recommend the Llama book, but then, I'm biased. ^_~
I do own my code that I write on my own time. On my employer's time, watch me ask him "Do you want me to spend twice as much time on it to make it portable?" The point is that there are other goals than portability - there's speed, maintainability, ease of implementation (and that *does* matter when the client says "I want it in a week").
If you want to argue that portable code is a basic human right, then obviously, you believe that Free Software (free as in speech) is a basic human right. Since it's possible to make a code unportable (if you have the source and the time), and since it's one reason Free Software is good (you can make stuff faster by doing it in assembly language) - you've hit a contradiction. The way to resolve it is: portable code is merely good, while Free Software is an absolute right (the other alternative, that portable code is an absolute right, doesn't work, because software must be Free to be portable)...
Also, if you get payed for cleaning up unportable code, why are you complaining? Would you prefer to be unemployed?
Become a FSF associate member before the low #s are used
Actually, having screenshots from a Windows box provides a ready answer to any questions about whether Perl CGI scripts will interoperate nicely with Windows clients. We know they will. That's the whole point of open, standardized protocols. But for managers who are firmly entrenched in the Windows' Proprietary Standards world, this is an issue. They are used to products that won't talk to the rest of the world. The idea that there is software out there that plays well with others is a new one to them. This may be the way to get your foot in the door.
The net will not be what we demand, but what we make it. Build it well.
I have this book, and it is good, but it requires a larger investment in time then many people who need to whip out a project have.
There's another book I have that's better suited for helping someone who needs to produce a CGI app over the weekend, and that's CGI101 by Jacqueline D. Hamilton.
Check out their website, it has the first few chapters online, and it's really well written.
www.cgi101.com
(I don't work for these people, but I benefited from this book when I needed to get something written from scratch and didn't know Perl or anything abuot CGI)
I got that book for my web designer girlfriend who had expressed an interest in learning what goes on ``behind the scenes'', and to be honest, after reading it I was way south of impressed. As a resource for the absolute novice to learn the language perl, I guess it's OK (although I still think the Llama book is better). As a reference for the absolute novice to learn CGI programming with perl, it blows monkey ass.
I feel this way becuase it mentions CGI.pm exactly once, in the context of ``it's too hard, just ignore it.'' Uhhhhh.... Yeah. Riiiiight. Programming CGIs in perl without using CGI.pm is about two incrememnts easier than just doing it in C. Using CGI.pm, it's about 100 increments easier. A tiny example is parsing form variables: it's a pain in the ass to get right by hand, it is one very short line of code with CGI.pm (see the param() function). I guess maybe she was trying to avoid mentioning what modules were, but how hard is it to understand that ``use CGI; $r = new CGI;'' makes $r hold a whole bunch of functions and stuff to make CGI easy? You don't have to be an OOP expert to use objects...
Now, I think Ms. Castro's HTML book by peachpit is pretty good. So evidently she just got in over her head or something with the perl book.
--
News for Geeks in Austin, TX
A web application needs to be tested. You can test it in your own favorite environment, but if you have some unusual hacked up thing (say, Englightenment running on Slackware, with your own private mutation of Mozilla, all with lots of customization) you're just going through the motions. You have test it in whatever environment your users are likely to use: Windows/IE, Windows/Netscape, Lynx, Opera, WebTV. Hey, if your typical user is running wget on Linux/Nintendo, get out your joystick and fire up the virtual keyboard. If you want to lecture the user on his stupidity, fine, but don't pretend that it's part of the design process.
Remember Thorvalds Law: the user is always right.
<RANT>
I'm getting pretty tired of slashdotters accusing each of being "kneejerk", "party line", "PC", etc. That itself is a kneejerk reaction, and a pretty lame one at that. If a post begins by accusing somebody of thoughtcrime, please reconsider. At best, you're being unnecessarily rude. At worst, you're thinking with your spleen.
</RANT>
__________________
__________________
I agree with him on two points: Unix browsers are pretty pathetic. (But I think Konqueror deservers a chance to mature a little.) And 11223 is most definitely a troll, as a browse of his recent posts will quickly confirm.
One question: is "GUNT" just a pun, or does it stand for something?
__________________
Oh come on. You and I use *nix on our desktop but you have seen the numbers we have all seen the numbers. The simple fact is if you take time to look at what they publish and what they put on their website O'Reilly are some of our best friends out there and they put out great books. Yup the screenshots are from winders and macs but guess what most of the people who look at the site that you run on your *nix server are going to be looking at it on winders or a mac. If you have looked at their pages and other books you would understand that this is just pragmatic it shows us where we are at. The website talks about where we can go.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
If you want to support the "*NIX is for servers, Windows and Macintosh are for desktops" party line, then buy this book. If you don't, then go elsewhere with your money.
humor for the clinically insane
great comedy company.
It's not really a Perl book - it's a CGI with Perl book, covering things like JavaScript. If you want to learn Perl get Programming Perl.
OTOH, if you just want a cgi script for your guestbook, you should reject Perl - that is unless you have, and want to learn how to use, mod_perl - otherwise it's very slow. Learn PHP by reading the excellent manual; see also the HOWTO.
Of course if you want to become an expert in some of the seriously sick bits of perl (it's oo functions, etc.), then you'll need a book (not this one though - AFAICT, this book is redundant - wouldbe Perl hackers should get a dedicated Perl book, while everyone else should use PHP or ASP).
Free Anne Tomlinson!!