CGI Programming with Perl 65
| CGI Programming with Perl | |
| author | Scott Guelich, Shishir Gundavaram, & Gunther Birznieks |
| pages | 451 |
| publisher | O'Reilly & Associates |
| rating | 9 |
| reviewer | chromatic |
| ISBN | 1-56592-419-3 |
| summary | Your guide to the protocols and practices of CGI programming, with a look at current tools, tips, and tricks. |
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
You can purchase this book at ThinkGeek.
Perl is the luggable of computer languages (Score:1)
CGI? (Score:1)
Re:Perl is the luggable of computer languages (Score:1)
The only problem is using Unix-specific functions (symbolic links, / as directory separator) on Windows
I did some Perl CGI stuff, deployed on a Linux box but I was writing and testing it under Windows (at work, while slacking off and pretending to be working). I had a constant called DIRECTORY_SEPARATOR which I set to "\" under Windows and "/" under Linux, until one day I discovered that you can actually use "/" OK under Windows. It doesn't need a "\" as a separator - that's just a COMMAND.COM quirk, not a DOS thing.
So there you go.
Re:Perl is the luggable of computer languages (Score:1)
Regarding Perl modules, if you don't know about the CPAN module, do "perldoc CPAN". Installing a module can be as easy as "perl -MCPAN -e 'install Date::Parse'"- --------------------
----------------------------------
Re:No (Score:1)
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.
Re:Shishir Gundavaram = crappy author (Score:1)
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.
--
Re:perl 6? (Score:1)
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.
--
Re:perl 6? (Score:1)
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.
Quickie Warning (Score:1)
Re:Quickie Warning (Score:1)
Re:Changes between editions? (Score:1)
Re:No (Score:1)
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.
Re:Another good book (Score:1)
Additionaly : ) CGI as a protocol is not outdated. It is inflexable, inefficent and some other adjectives but it still fills it's role nicely.
Re:No (Score:1)
Re:Perl is the luggable of computer languages (Score:1)
Second, If you have problems going from x86 to sparc with perl, you're a poor perl programmer, if that's the case stick to something you (quite obviously) are more familiar and happy with: Java.
Don't spread your FUD about a great programming language though.
Re:Perl is the luggable of computer languages (Score:1)
No, because in order to get anything done in cgi, you have to use lots of those "unix-specific functions" you allude to
Just in case you've not seen this, there's a project underway to re-implement most common UN*X commands in Perl
Find it here http://language.perl.com/ppt/what.html [perl.com]
These tools can be used on multiple systems, and can be used if you think you need a Unix command...
Steve
---
Re:Perl is the luggable of computer languages (Score:1)
It is however more specifically designed to be more portable among various UNIX platforms, eg. the inclusion of the fork() function, STDOUT, etc. and thus my opinion is that the standard bread and butter Perl is leaning towards UNIX.
Java on the other hand has no platform specific language constructs. It has neither fork() or STDOUT, nor any other language features that lean to Windows or Unix.
Perl libraries are great, but the trouble is that they are not always portable. This is where the portability issues with perl get ugly, and java really shines. For example, have a look at all the Win-32 modules available on CPAN that do not run on UNIX versions of perl and vice-versa.
With java, the library is always guaranteed to run on one platform (the JVM).
As for java being unportable from 1.1 to 1.2, The difference between 1.1 and 1.2 (in theory) is only the library! So in order to port 1.2 apps to 1.2 all you have to do is download 1.2 libs for your 1.1 JVM. However, if you want to port your app from 1.1 to 1.2 then you do not need to do anything, since 1.2 is backwards compatible.
I'm not saying that Java is better. I believe that both languages have their uses for their own specific tasks, and should be mostly compared for that!
perl 6? (Score:1)
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.
Re:perl 6? (Score:1)
Thanks much. I saw a reference to Perl 6 recently and thought it had been released. Maybe Larry's just been thinking out loud.
here's how, in perl (Score:1)
$random = int(rand 10); # random number, 0-9
Alternatively, use the CPAN module Math::TrulyRandom
HTTP upload (Score:1)
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 [slashcode.com] still hadn't worked out how to do this. Perhaps chromatic should donate his copy to pudge?!
Re:Do you think.. (Score:1)
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.
Re:Do you think.. (Score:1)
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
Re:Perl book recommendations (Score:1)
--
Perl is unaplogetic itself (Score:1)
Disagree. (Score:1)
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.
Changes between editions? (Score:1)
Richy C. [beebware.com]
--
Do you think.. (Score:1)
Perl and CGI (Score:1)
Of course, to be a REAL master, don't forget to purchase "Mastering Regular Expressions" from Orielly as well!
Yeah, yeah (Score:1)
Re:Perl is the luggable of computer languages (Score:1)
OK allow me to make a quick rant about the whole serverside java thing. Many people are extoling the virtues of EJB and servlet solutions to replace the existing CGI solutions. The constantly extolled virtues of which are that you dont have continuous startup times. You start your WebSphere/WebLogic/Whatever server, it loads your EJBs and servlets once and they get recycled.
However IMHO this has one major flaw versus the one request/one process CGI methodology. Suppose someone decides to submit crap input to you. Your CGI starts up, bombs out and cant return a response. When the next request comes in a new process is started so the error from the last request has no effect, it starts over with a fresh slate. However with the EJB solution you now end up with one of the EJBs in your pool trashed, and it is still sitting around to be recycled for more requests. So if anything happens that your java bombs the "broken" EJB is still kept going to cause more problems. This means that you have to do an awful lot more testing for EJBs and Servlets than you do for CGI.
There is also the problem that java wont crash (bear with me here for a second). If someone sends a load of crap to your CGI causing something invalid to happen it will core dump. Do the same to java and it throws an exception and hangs there. So if you write your server in C/C++ whatever and it bombs, well theres a cron job that restarts it straight away, clean slate and off it goes. Your java app will never die. So if anything happens then it is likely to keep slogging along in its corrupted state until someone spots it and restarts it.
Now a fully tested java solution can be great but it needs a lot more bulletproofing than other similar solutions. For commercial enterprises thats probably ok (after all it is great to brandish the java/ejb/servlet buzzwords) but for anyone without the extensive testing resources that corporations have it can be a lot of work.
Re:Perl is the luggable of computer languages (Score:1)
But that's the Java philosophy. What would be the point of Perl imitating it when Java already fills that niche?
mod_perl != cgi (Score:1)
Shishir Gundavaram = crappy author (Score:1)
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.
Re:No (Score:1)
I recommend this book (Score:1)
Save some money (Score:1)
Re:No (Score:1)
Previous Edition is Free (Score:1)
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. [oreilly.com]
Re:Previous Edition is Free (Score:1)
But, anyway, what I had read about optimizing mod_perl [kcilink.com] said in the first sentence: CGI.pm is a big module that by default postpones the compilation of its methods until they are actually needed.
On the other hand, if you're running mod_perl (which you would to speed up that CGI lag you mentioned), as that page points out, you would want to
use CGI;
CGI->compile(':all');
And that would increase the memory for each child process (apache) you might be running.
Of course, if you're running a nice fat system without heavy demands on it, who cares?
If you're optimizing a system and really aren't making heavy use of CGI.pm's convenient features, you might care. CGI is the only game in town for a lot of things, and for the most part, apache/mod_perl makes it pretty efficient.
Re:HOWTO - Elect a Government (Score:1)
l33t j03, posting anonymously because Taco has banned me.
Re:Previous Edition is Free (Score:1)
Nonsense.
Here is the "delay" myth.
[FHBTA@thepen]%time perl -MCGI -e ''
0.09user 0.04system 0:00.13elapsed
Man, thats a long time. CGI doesn't export anything unless you make it.
And about all that memory...
[FHBTA@thepen]%ls -l CGI.pm
190905 CGI.pm
Oh my, 190K file size. Now, one of the nice things about CGI.pm is that over half the size of the module is POD. The real size of the module is closer to 60K. My, that's huge.
If you're implementing CGI in Perl, you're a fool not to use CGI.pm. If runtime speed is the issue, you're a fool to implement in CGI, in any language.
--
Re:Previous Edition is Free (Score:1)
If you are worried about performance, don't use CGI at all. Use something else.
If you're running mod_perl, you aren't running CGI.
mod_perl != CGI.
--
Perl book recommendations (Score:2)
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) [oreilly.com].
If you just want some scripts to copy, look on the web or get the Perl Cookbook [oreilly.com].
And if you want to learn advanced Perl stuff, and enjoy extreme pain and an awkward writing style, get Advanced Perl Programming [oreilly.com].
I recommend the Llama book, but then, I'm biased. ^_~
Re:here's how, in perl (Score:2)
Re:Perl is the luggable of computer languages (Score:2)
Re:HTTP upload (Score:2)
Re:Perl is the luggable of computer languages (Score:2)
As for the unix-specific funtions, what kind of CGI scripts do you write? I've been doing a lot of CGI programming over the last 2-3 years and 99% of the time all the CGI does is take the form input, process it a bit, and stick it in an SQL database (or take data from an SQL database and display it, as the case may be). All this requires is using the DBI module, which is perfectly portable.
Re:I'll make it 100% necessary (Score:2)
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?
Re:Shishir Gundavaram = crappy author (Score:2)
Re:It would be nice.... (Score:2)
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.
Another good book (Score:2)
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)
Re:Perl is the luggable of computer languages (Score:2)
Having just spent the last month or two messing around with perl on win98 and SuSE Linux I reckon that you're talking crap. I have had next to no problems with cross-compatibility and have found that if i need to make calls to the shell then there is probably a better way to do it within perl. But as I said, I'm not very knowledgeable about the intricacies.
The second thing is that if you are writing something that you can't port without much difficulty then you should perhaps consider writing it natively in C in the first place.
Couldn't disagree more :-) (Score:2)
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.
--
Re:Do you think.. (Score:2)
Definitely not. I have and use this book all the time, but I use it for specfic cgi questions and problems. To learn Perl, I wouldn't really bother with a class. I'd just get the O'Reily Perl CDROM bookshelf and start with Learning Perl. This is a good deal, there's six books on the cd that will take you from novice to adept and provide enough quick reference material to solve any problem. The cgi book on the other hand is a great book for someone who's got a pretty good foundation in Perl, but is new to cgi programming.
I think you've wandered into the wrong discussion (Score:2)
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 [rambler.ru], please reconsider. At best, you're being unnecessarily rude. At worst, you're thinking with your spleen.
</RANT>
__________________
Re:I think you've wandered into the wrong discussi (Score:2)
__________________
Troll Appeal (Score:2)
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 [slashdot.org] will quickly confirm.
One question: is "GUNT" just a pun, or does it stand for something?
__________________
Re:It would be nice.... (Score:2)
It would be nice.... (Score:2)
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.
Another Perl/CGI Reference (Score:2)
humor for the clinically insane [mikegallay.com]
No (Score:2)
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 [php.net]; see also the HOWTO [linuxdoc.org].
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).
Re:Perl is the luggable of computer languages (Score:2)
I think you mean 'unlike languages like java, you can almost always take it with you.'
> Going from sparc to x86 and vice versa has always been a headache.
No, there's no problem there, since Perl is a highlevel scripting language.
The only problem is using Unix-specific functions (symbolic links, / as directory separator) on Windows and vice-versa (e.g., using COM).
Re:It would be nice.... (Score:2)
Re:Perl is the luggable of computer languages (Score:5)
Compared with this, java is nearly un-portable: many environments are still in the migration toward java 2; and parts of the language can be a major headache, even if they work as announced (ever tried to store BLOBs via JDBC in Oracle? ;-)
last not least: Perl Modules are, on the average, very easy to install, and with CPAN there exists a simple method to find relevant modules.