Slashdot Mirror
Wicked Cool Perl Scripts
Michael J. Ross writes "Of all the popular programming languages now in use, Perl is perhaps the best suited for writing utilities — for several reasons, such as its text-processing capabilities, ease of addressing system resources, and minimal language overhead for input, output, list processing. It was designed to blend the rapid solution development of shell scripting with the powerful control constructs of third-generation languages. Consequently, Perl quickly became a favorite language for developing programs ranging from system administration utilities to CGI scripts that power Web sites. In fact, Perl has been called the glue that holds the Internet together. The tremendous flexibility and power of Perl is seen in Steve Oualline's book Wicked Cool Perl Scripts: Useful Perl Scripts That Solve Difficult Problems." Read the rest of Michael's review
Wicked Cool Perl Scripts
author
Steve Oualline
pages
336
publisher
No Starch Press
rating
8
reviewer
Michael J. Ross
ISBN
1593270623
summary
47 useful Perl scripts for Web site management or CGI, Linux or Unix system administration, managing pictures, etc.
Published by the cleverly named No Starch Press, Wicked Cool Perl Scripts comprises 336 pages, spanning 11 chapters, with a brief introduction, as well as an index. The book appeared in February 2006, and was published under the ISBN of 1593270623. No Starch Press maintains a Web page for the book, where readers can find a sample chapter (the third one, covering CGI debugging), in PDF format. There is a link for downloading all of the source code.
The book presents 47 scripts, grouped into 11 categories: general-purpose utilities, Web site management, CGI debugging, CGI programs, Internet data mining, Unix system administration, picture utilities, games and learning tools, development tools, mapping, and regular expression graphing. The scripts perform such functions as finding duplicate files on your PC, converting currencies, processing error logs, generating jokes randomly, getting stock quotes, and managing photos and other images. Some of the scripts play games, while others would be invaluable to any Linux or Unix system administrator. For readers with their own Web sites, the book offers scripts for verifying links, locating orphan files, detecting hackers, and locking them out. In addition, there is a script for counting the number of visitors to your site, and even one for presenting a guest book. Software developers will find the material valuable, as there are Perl scripts for generating code, locating dead code, and handling regular expressions — parsing and graphing them.
The scripts themselves are fairly wide ranging in complexity and size, with a few fitting on a single page of the book, while others require more than ten pages. Fortunately, the scripts generally contain enough comments to be clear in how they work to any programmer comfortable with the language. Nonetheless, the author explains how to run each script, what sort of results the reader should see, how the script works, and what modifications one might want to make to it ("hacking the script"). In addition, every one of the scripts contains a POD (Plain Old Documentation) section, though only in the downloadable version — not the version seen in the book, to save space.
It is doubtful that any beginning Perl programmer might mistake this book for a Perl primer or reference. The title alone makes clear that the focus is on the offered scripts themselves, and their ability to help the reader solve common problems. On the other hand, Perl programmers of any level of fluency with the language would benefit from reading through the scripts, as well as the author's explanation of how they address and solve each problem. I myself have been programming in Perl for ages, and yet I spotted CPAN modules that I can use in my own Perl scripts in the future.
The value of the scripts themselves to each individual reader, naturally depends upon what sort of tasks the reader would like to accomplish with Perl. The 11 categories of scripts are varied enough so as likely to be of use to just about anyone who would like to use the "Swiss Army knife of languages" for getting the job done on their computer, or that of their employer (as a system administrator). Personally I found most useful the scripts for detecting changed files, scanning Web sites for dead links, and parsing regular expressions.
There are other aspects to like about this book. It has a RepKover binding, to lay flat when open. The illustrations are clear and not excessive in number. Unlike some technical authors, whose weak attempts at humor simply make their obtuse material more annoying, Oualline is more subtle, such as his reference to the cost of Microsoft Windows CDs in a Hong Kong shop, or "Ingesting a Cheerio nasally." Well, perhaps not always subtle, but invariably welcome in what could otherwise be an extremely dry subject.
Like any book, there are some areas for improvement, perhaps in future editions: In the illustrations that employ rays pointing from one node to the next, some of the curved rays are remarkably jagged, as if they were not computer-generated. Far more importantly, some of the scripts could benefit from more internal comments, as well as having the code broken up into smaller functions, which improves clarity and maintainability. Also, some of the variables and functions could use more descriptive names. For instance, using two examples from a randomly chosen page: $file_name would be more clear than $cur_file (is it the file's name, full path, or contents?). print_file_cell() would be better than do_file() (do what to the file?).
But aside from those weaknesses, Wicked Cool Perl Scripts is a fine book that would be of interest to any Perl programmer, regardless of their expertise. In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com.
You can purchase Wicked Cool Perl Scripts from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Published by the cleverly named No Starch Press, Wicked Cool Perl Scripts comprises 336 pages, spanning 11 chapters, with a brief introduction, as well as an index. The book appeared in February 2006, and was published under the ISBN of 1593270623. No Starch Press maintains a Web page for the book, where readers can find a sample chapter (the third one, covering CGI debugging), in PDF format. There is a link for downloading all of the source code.
The book presents 47 scripts, grouped into 11 categories: general-purpose utilities, Web site management, CGI debugging, CGI programs, Internet data mining, Unix system administration, picture utilities, games and learning tools, development tools, mapping, and regular expression graphing. The scripts perform such functions as finding duplicate files on your PC, converting currencies, processing error logs, generating jokes randomly, getting stock quotes, and managing photos and other images. Some of the scripts play games, while others would be invaluable to any Linux or Unix system administrator. For readers with their own Web sites, the book offers scripts for verifying links, locating orphan files, detecting hackers, and locking them out. In addition, there is a script for counting the number of visitors to your site, and even one for presenting a guest book. Software developers will find the material valuable, as there are Perl scripts for generating code, locating dead code, and handling regular expressions — parsing and graphing them.
The scripts themselves are fairly wide ranging in complexity and size, with a few fitting on a single page of the book, while others require more than ten pages. Fortunately, the scripts generally contain enough comments to be clear in how they work to any programmer comfortable with the language. Nonetheless, the author explains how to run each script, what sort of results the reader should see, how the script works, and what modifications one might want to make to it ("hacking the script"). In addition, every one of the scripts contains a POD (Plain Old Documentation) section, though only in the downloadable version — not the version seen in the book, to save space.
It is doubtful that any beginning Perl programmer might mistake this book for a Perl primer or reference. The title alone makes clear that the focus is on the offered scripts themselves, and their ability to help the reader solve common problems. On the other hand, Perl programmers of any level of fluency with the language would benefit from reading through the scripts, as well as the author's explanation of how they address and solve each problem. I myself have been programming in Perl for ages, and yet I spotted CPAN modules that I can use in my own Perl scripts in the future.
The value of the scripts themselves to each individual reader, naturally depends upon what sort of tasks the reader would like to accomplish with Perl. The 11 categories of scripts are varied enough so as likely to be of use to just about anyone who would like to use the "Swiss Army knife of languages" for getting the job done on their computer, or that of their employer (as a system administrator). Personally I found most useful the scripts for detecting changed files, scanning Web sites for dead links, and parsing regular expressions.
There are other aspects to like about this book. It has a RepKover binding, to lay flat when open. The illustrations are clear and not excessive in number. Unlike some technical authors, whose weak attempts at humor simply make their obtuse material more annoying, Oualline is more subtle, such as his reference to the cost of Microsoft Windows CDs in a Hong Kong shop, or "Ingesting a Cheerio nasally." Well, perhaps not always subtle, but invariably welcome in what could otherwise be an extremely dry subject.
Like any book, there are some areas for improvement, perhaps in future editions: In the illustrations that employ rays pointing from one node to the next, some of the curved rays are remarkably jagged, as if they were not computer-generated. Far more importantly, some of the scripts could benefit from more internal comments, as well as having the code broken up into smaller functions, which improves clarity and maintainability. Also, some of the variables and functions could use more descriptive names. For instance, using two examples from a randomly chosen page: $file_name would be more clear than $cur_file (is it the file's name, full path, or contents?). print_file_cell() would be better than do_file() (do what to the file?).
But aside from those weaknesses, Wicked Cool Perl Scripts is a fine book that would be of interest to any Perl programmer, regardless of their expertise. In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com.
You can purchase Wicked Cool Perl Scripts from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.
... therefore you don't know what's actually going on with your own machines? Write your own scripts script kiddies.
Is these really that good of a practice though? Your pc's will be jam-packed with go you never wrote
While it is important that the Admin completely understands what is going on.... theres no need to re-invent the wheel if someone else already went through the trouble of writing and testing it.
Than googling for cool perl scripts?
I'm asking seriously, because of all of the "cookbooks" and collection books of this sort that I've seen on the shelves at Borders, they're all full of things that a quick bit of googling could come up with. In fact, a little searching usually yields better solutions, and I'm convinced they're written by copy/pasting google results into the author's editor of choice.
I'm all for good dead-tree reference material, but I've been frustrated trying to find books that don't contain stuff-i-already-know, or stuff-i-can-get-free on the 'net.
I guess it can't be good for the dead tree tech manual industry, but so long as universities and colleges force students to buy the books (and a new revision of the same book every year), that's all fine and good.
I don't need no instructions to know how to rock!!!!
Why is it that every scripting book needs a title that sounds like it was written by a 14-year old?
"There's more than one way to do it" should not be considered a personal challange to find them all
Perl is the most wonderfully architected, elegant, flexible language in the world. It's like a fully stocked kitchen with everything you'd ever need to get the job done, and more. Any new version of Perl would be a step backwards.
See, we can both make absolutist, arbitrary statements with no basis in reality. Fun, eh?
Hey!! Perl has real objects... you just have to work at it...
Of course, being a Perl programmer, I am very averse to work, hence all the time I spend reading Slashdot.
GetOuttaMySpace - The Anti-Social Network
A humble Perl user's thoughts on this brouhaha --
Praise
=======
1) The power of perl is irrefutable -- it helps slap together quick and clean solutions to irritating admin problems. The flip-side of being a perl jockey I guess is that one tends to try and create a solution to many a problem that already has a solution - because searching CPAN can be a pain at times.
2) Use of the more flexible features of the languages (such as Hashes, hash of hashes etc) data/number munging and organization becomes more manageable.
3) Using Perl's almost endless modules, a lot of relatively complicated tasks can be simplified.
4) Annoyance factor of numerous tasks (especially Administrative and reporting) can be reduced drastically with the help of Perl.
Beefs
=====
1) The beef I guess is that unlike Python or Perl's other competitors, Perl modules don't come tightly integrated with the core distro. Agreed that Perl probably has a lot more modules than any of those other languages do, but a larger than ordinary de facto distribution (why not include important modules like Digest::MD5, Crypt modules, SSH modules etc?) would be desirable (especially in those situations where you don't have access to the internet directly from within corporate networks and can't install the modules with the "perl -MCPAN -e shell" option) . There might be those Perl veterans who would say -- "build your own distro with your custom modules already packaged" -- and while that might be a very smart thing to do, many a time (when one keeps moving from one environment to another -- some call it job hopping, it helps to be able to download one single perl distro package or rpm or the source+compile and have basic administrative scripts work -- especially those that rely on centralized automation (ssh-based trusts, copies across the network, etc).
2) Also, perl's syntax can be terse and difficult for noobies to understand (or even older perl-hands for that matter -- when someone has written code without appropriate comments, etc).
3) Tinkering with Python recently, I found it's simplicity refreshing and it's syntax easier to comprehend (especially when compared with Perl's (imho) complicated "scoping" requirements, etc).
4) Sometimes (and I guess it depends on the person writing the code) Perl tends to over-complicate things that can be easily handled via Shell scripts.
It seems as if all they did was wrote a basic clock program and then ran it through an obfuscator or two. You can get a few obfuscation modules on CPAN. Anybody can run a program through obfuscators. Ever tried to look at the google maps javascript?
The exit statement at the end is unnecessary.
Python - Put Your Tin Hats ON!
I have those two reasons, but those are soft factors, nice-to-have, but not necessary. Unfortunately, I have a third:
3) unicode
I have to deal with lots of unicode, index it, run regexes on it, and so on. Ruby lacks any real unicode support, which has made it a deal-breaker.
Done with slashdot, done with nerds, getting a life.
With its awful syntax, Perl is arguably the worst language for writing any utilites. Python and Ruby are a lot better.
You've got real objects when you want them. LISP-like things like iterators and closures. The works.
I don't want this to degenerate into rabid fanboyism, but it seems the benefits of a "real" (or, real, if you preffer) object system over Perl's are routinely exaggerated. Yes, it could be better, but for 95% of the things you do, it works just fine.
And of course Perl has iterators and closures (and first order functions, and all that other hard-to-maitain stuff the Functional crowd always goes on about). It's probably one of the things I like best about Perl, it just has features as part of the language, no one makes a huge deal of it.
I've looked at Ruby (ok, glanced), and I just can't stomach the syntax - it's like writing Java in VB. Entirely subjective, of course. Though, as long as I live I will not understand this recent fad of trying your best not to delimit code blocks clearly - it smells of choosing ideology over utility.
Definitely agree about the lack of "simple and rigid" struct-like things, I miss those often.
And of course for anyone who wants a feature that Perl doesn't have, there's Perl 6 - that will have every feature that has existed in any language, ever.
sic transit gloria mundi
I don't see how you could read any books about Perl and not have any idea where the language came from. This is why PHP is so much more popular than Perl among people who don't already have a familiarity with UNIX and C: a C programmer learning Perl can say "oh hey, perl has a localtime() function, I already know how to use that" while a newbie will say "wtf, why do months start with 0 and the year is 106, and how am I supposed to remember what order all these numbers are in?" A UNIX hacker can say "oh hey, $0 and $$ are exactly the same as they are in shell scripts, and the regex syntax looks just like sed" while a Windows user will say "wtf, what are all these meaningless variables, and what the hell is a regex?"
My advice for OOP in Perl:
1) learn how OOP is supposed to work in some other language
2) pretend that it works that way in Perl, and try not to think about how "bless" actually works.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
In fact, Perl has been called the glue that holds the Internet together.
That's not true. C was considered the glue of the Internet... Perl is the gaffa tape.
I'm giving in this time.
I work in a shop where we maintain (after last count) 112,002 lines of perl in a single system (which also contains about half a million lines of C).
Guess what? It's not a problem! Not in the slightest!
And you know why?
- Modules
- Coding conventions
- Mature programmers
Two of those three are redundant. Take a guess which ones (the third item isn't part of the anwer set).
If you take a programmer that writes disciplined, careful, extensible, extendable and professional C - are they going to start generating hacked up crap when they switch to Perl? No. They're not. They split source among modules. They use naming conventions. They use strict. They use the namespaces. They use clear syntax. The end result looks almost like C most of the time. Except when it doesn't, 'cause it's Perl.
What does C written by hack-job Perl "programmers" look like?
Rephrasing #37 - "It ain't the arrow, it's the (Native American)".
Fire your perl guy -- he's clearly a menace. And after you fire him, tell him to stop reading perlmonks.org. After a while, he'll start doing things like using foreach() instead of map() when it makes the script clearer. And as an added bonus, he won't waste time trying to find the bug he caused from overwriting $_ with a regex or whatever.
There's no reason not to write maintainable code, perl included. That you get the choice with perl is a design goal of the language, and it's a good thing in general. But why neophytes always try to put the newest, cleverest toy they discovered into every script they write is beyond me...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Seriously. Incomprehensible and unmaintainable code can be written in any language, but in Perl even good code is unreadable.
:)
It can be unreadable, but that doesn't mean that it is. Code can be good for lots of reasons- not just legibility
Perl is probably the language with the highest chance of accepting the output of a random number generator as a valid program.
That honor belongs to sendmail; We used to offhook the telephone couplers whenever someone had messed sendmail.cf up to get a good working setup from the line noise that'd leak through.
I've seen a lot of both.
Really shitty, unreadable Perl that makes your head hurt. Stuff that was only designed to execute from top to bottom like a shell script and it only works in the context of some main file. Won't even run if you use sttrict.
And beautiful, expressive object-oriented, properly packaged stuff that lets you plug and test it any which way. Stuff you aren't afraid to instrument, modify, or implement because you just understand the author's intent.
They look almost like two different languages.
Then again, I think this is what happen when you have languages that have a lot of built in functionality blessed with tersity and "reasonable defaults".
You can't write spaghetti code in a more structured language like Java or C that does anything useful without code generation.
Perl makes it possible even without syntax highlighting.
It's _too easy_ on the programmer.
*shrugs*
It's like VB... except you had a web GUI with a simple "use CGI". And pervasive regular expressions (which, IMHO, is the thing that makes perl unreadable if you don't learn about the m//x modifier).
In 1999.
So anytime you go online searching google for a Perl script that does XYZ, you end up on one of those code-sharing sites full of "consultants" idiots and you've got the worst kind of code floating around there. Copy and pasted crap with no structure... just hacked up until it works.
And Perl's permissiveness allows it to proliferate.
I just write everything myself, or get it from CPAN.
CPAN at least acts as a kind of quality control.
If you want to see how to write or model your code, use CPAN modules as examples. You learn alot.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
For the most part the POSIX C API uses NUL terminated strings, pointers to structs, and ints (and opaque types that are actually ints). Oh, and small structs made up of that stuff. :-D
Perl's scalar numbers internally are the same size as the system's ints, so that handles that detail.
Perl auto-coerces strings to numbers and vice-versa. So it can handle the number and string arguments using built-in API functions that just take whatever perl expression and coerce it down to the appropriate scalar context in the glue code. Functions that wanted structs and pointers to them (say, like gettimeofday, select or localtime) would be handled at function call time -- the memory allocated only lasted as long as it was needed to issue the call and copy the return value into the result array for the caller.
You had to actually include perl modules that defined all the constants you would otherwise get from say, stdio.h or sys/types.h since perl didn't know about them (like O_RDWR, SEEK_SET, and all that stuff). Or you could hardcode constants.
Yeah, and you'd read Perl man pages and they'd caution you how the behavior of a lot of those bare functions were OS dependant, subject to the OS's specificities (AIX, Linux, Solaris, VMS and Windows, Oh My!). I.E. Linux's select would modify the time left to wait, while Solaris's didn't specify either way (until they introduced pselect(), which didn't, and changed select() so it always did).
Which is why the invented Perl IO and IO::Socket, and they introduced "Perl threads" -- so you could do stuff that was close to bare metal without worrying about niggling platform details.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
C and Perl are for professional programmers. Ruby and Python are for people who need to write short programs from time to time, better than VB, of course, but no substitute for professional quality tools.
I have to call BS on this one. I highly doubt that the parent poster has seen the ubiquitous pile of legacy Perl code lying around, and how bad and bug-ridden it can be because the programmers didn't do enough to control a sloppy language. I think Perl Medic is the only Perl book I'll ever recommend for that reason.
Based on years of professional and hobby experience, I'd keep Perl around for 100 line one-off scripts and no more. Perl's flaws as a language have bit down hard anywhere where multiple programmers had to collaborate on a sizable project or maintain it over a period of time. The amount of nonsensical boilerplate is tremendous. Having to shovel more of it to force what is essentially an sh script with everything in the world tacked on just to keep its variables non-global is the precise opposite of what a serious language should do. And the language even lets a freestanding next or last statement in a function break loops in the calling function! Try being on a team with sloppy programmers with those kind of design flaws running loose.
That was the past. I now work in a Silicon Valley startup where we use Java and Python, depending on the kind of work being done. Python's design scales far better for application development, with good modularization and OO done right without extra judo moves just to force behavior. The Ruby and PHP people seem pretty happy too.
Perl was good in its day. Other languages have long since surpassed it. Let it go the way of COBOL.