Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Wicked Cool Perl Scripts 239

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.
This discussion has been archived. No new comments can be posted.

Wicked Cool Perl Scripts

Comments Filter:
  • by fprog26 ( 665694 ) on Wednesday June 28, 2006 @03:52PM (#15623488)
    Your solution was a bit too C++ and won't compile with perl, so you probably meant the following... :)

    #!/usr/bin/perl
    #
    # Program -- Solve it -- Solves the worlds problems.
    # All of them. At once.
    # This will be a great program when I finish it.
    #

    sub main()
    {
    # no idea at all...
    }

    main();
    exit;
    1;
    __END__

    or the even better, the POD way:

    #!/usr/bin/perl

    =head1 GOAL
    Program -- Solve it -- Solves the worlds problems.
    All of them. At once.
    This will be a great program when I finish it.
    =cut

    sub main()
    {
    # no idea at all...
    }

    main();
    exit;
    1;
    __END__
  • Re:Overhyped (Score:2, Interesting)

    by maximthemagnificent ( 847709 ) on Wednesday June 28, 2006 @04:08PM (#15623582)
    I learned perl coming from a c++, Java background and I found it really, really ugly.
    Not that I've learned any other scripting languages to have some comparison, admittedly.
  • by rgmoore ( 133276 ) * <glandauer@charter.net> on Wednesday June 28, 2006 @04:28PM (#15623720) Homepage

    That looks as though you don't know Perl very well. There's no need for a separate main routine, as whatever is in the file that's not part of another subroutine is assumed to be part of main. There's also no need to have the program end in a true statement (that's necessary only for modules) or to use an __END__. In the true spirit of Perl (i.e. eliminating needless elements) here's a refined version:

    #!/usr/bin/perl

    =head1 GOAL
    Program -- Solve it -- Solves the worlds problems.
    All of them. At once.
    This will be a great program when I finish it.
    =cut

    use warnings;
    use strict;

    #Do something here

    exit;
  • Re:Solve it (Score:3, Interesting)

    by Jerf ( 17166 ) on Wednesday June 28, 2006 @04:28PM (#15623723) Journal
    Perl is an overly complicated, syntactically-challenged, unstructured kitchen sink of a language. The next major version of perl needs to be developed with more of a plan, and less of a "a little of this, and a little of that" philosophy.

    Rest assured, Perl 6 has planning in abundance.

    You'll probably be less happy to learn that the guiding principle seems to be a "lot of this, lot of that" philosophy.

    But, this time with a plan.

    (My personal call on Perl 6? It's time to just ship it. Whatever "it" is. After a while the value lost to not having anything at all outweighs the cost of shipping nothing useful. Although, honestly, I'd rather see a useful Parrot that makes it possible to run Python, Perl, Ruby, and TCL through the same VM than Perl 6.)
  • Re:Clarification (Score:4, Interesting)

    by Vorondil28 ( 864578 ) on Wednesday June 28, 2006 @04:28PM (#15623725) Journal
    You're argument against Perl is:
    1. Slashdot is written in Perl.
    2. I don't understand the error message I got when attempting to post on Slashdot.
    3. Therefore, Perl code is incomprehensible and unmaintainable.


    You, sir, are a veritable fount' of wisdom...</sarcasm>
  • by Sarusa ( 104047 ) on Wednesday June 28, 2006 @04:40PM (#15623816)
    'Of all the popular programming languages now in use, Perl is perhaps the best suited for writing utilities'. I would probably agree with this - you can very easily hack out a very simple utility to do something with less effort and code than in Ruby or Python. Of course if you ever need to read it again, or god forbid extend it, then the extra effort you put in up front may pay off.

    Yes, I know you can write very readable maintainable perl. In theory. The only example of this I have ever seen is the Calcium web calendar. But whenever our perl guy writes something it looks more like
        ($l=join("",))=~s/.*\n/index($`,$&)>=$[||print$&/g e;
    (stolen from http://www.antipope.org/charlie/attic/perl/one-lin er.html [antipope.org]) and if he has to touch it again a month later it's a dangerous thing.

  • Evil Perl (Score:4, Interesting)

    by Michael Woodhams ( 112247 ) on Wednesday June 28, 2006 @04:46PM (#15623859) Journal
    Version 1:
    @a{($b=pop)=~/\w/g}=@a=0..9;$a="@{[keys%a]}";sub
    a{@a?map@a=(a(@_,pop@a),@a),1..@a:($_="$b
    ",eval"y,$a,@_,",/\b0/)||eval&pop}a

    Version 2:
    while($_=$a=pop){/([a-z])/i?map{($t=$a)=~s/$1/$_/g ;$a!~/$_/&&push@ARGV,"$t
    "}0..9:/\b0\d/||eval&&print}

    They do the same thing. I'll post what that is in a follow-up, for the sake of any masochists who want to figure it out for themselves.
  • by Tankko ( 911999 ) on Wednesday June 28, 2006 @04:47PM (#15623873)
    I have a bunch of "cookbooks", and I don't read them because I'm looking for a specific solution, I read them because it's a great way to learn a lot of tricks and see a lot of code in a concentrated place that covers a bunch of areas.

    I sit on the couch and just read them and learn a lot.
  • Re:OB Ruby fanboyism (Score:2, Interesting)

    by loquacious d ( 635611 ) on Wednesday June 28, 2006 @05:00PM (#15623963)
    I agree on all points. I also find the average Ruby script infinitely more readable than most of the Perl I've read (or written). Ruby's syntax is just so perfect and clean. I was pretty skeptical when I first started reading Ruby books, the way everyone always waxed so ridiculously lyrical about how writing Ruby after using other languages was like a walk in a park on a damp spring day with the sun just barely shining through the low wispy fog etc. etc. etc. But it's true. I hope it can maintain its momentum, the world would be a better place if people spent as much effort learning/improving/extending Ruby as they did Java (*shudder*).
  • Perl is VB (Score:2, Interesting)

    by Anonymous Coward on Wednesday June 28, 2006 @05:22PM (#15624114)
    I'll preface by saying that there's nothing inherently wrong with VB or with Perl. The problem occurs because both *can* foster poor programming practices. Both have an immense library of functions that allow novice scripters to hack together scripts that can perform a function. There may not be any overall design, but for lots of folks, this is more than enough. The problem occurs when you try to maintain that code (either Perl of VB) and you realize that people have pulled together modules (or ActiveX contols) that do the job, but are probably the worst or next-to-worst way of doing things. In other words, Perl and VBs downfall is their success.

    It just seems that other languages (Java, Ruby, Python) are more rigorous -- maybe because the learning curve is *slightly* higher. It's easier to write proper code in these languages because the design of the language almost enforces it.
  • Re:My Ex-Language (Score:5, Interesting)

    by esconsult1 ( 203878 ) on Wednesday June 28, 2006 @05:24PM (#15624132) Homepage Journal
    So right.

    Look over the perl 6 syntax and the increased punctuation, then compare to Ruby. I've been working with perl now for about 10 years or more, and Ruby has replaced or supplanted all my Perl work over the last several months. No going back. Not even bothering to learn Perl 6. CPAN is sweet, but so much is already built into ruby's standard libs.

    Ruby syntax is clean. Real OOP. Self documenting. No way I'm going back, especially not for Perl 6, which is too much, and too late.

  • Re:"Wicked" Cool? (Score:2, Interesting)

    by Darby ( 84953 ) on Wednesday June 28, 2006 @05:35PM (#15624217)
    To our readers on the West Coast:

    Please replace every instance of "Wicked" with "Hella" to improve readability.


    That's only the Bay area.
    Even the rest of California really wants them to quit using that stupid sounding term.

  • Re:Solve it (Score:4, Interesting)

    by grcumb ( 781340 ) on Wednesday June 28, 2006 @05:41PM (#15624266) Homepage Journal

    "Perl is the most wonderfully architected, elegant, flexible language in the world."

    Indeed. In fact, it's the only language in the world that can guarantee perfect software [cpan.org], every time. Even when you're drunk [cpan.org]. 8^)

  • Re:OB Ruby fanboyism (Score:4, Interesting)

    by esper ( 11644 ) on Wednesday June 28, 2006 @06:55PM (#15624683) Homepage
    "Inside-out objects" can give you hard data hiding. Basically, instead of storing the object properties as keys of a blessed hash, you have a file-scoped (my) array for each property. Nothing outside of that file can access the data and the object becomes a blessed integer reference (used as an index into the property arrays) instead of the blessed hash reference that's normally taught. (This can also be implemented with hashes for each property and the blessed reference itself used as the hash key, but I tend to prefer the array version, since the lookups are a good deal faster.)
  • by mangu ( 126918 ) on Wednesday June 28, 2006 @07:12PM (#15624772)
    Ruby has the completely useless "end" statement they borrowed from FORTRAN77 and Ada. Stupid, stupid, stupid, how stupid can you get?


    Every text editor I know and use can match braces. Where does this block end? By clicking one or two keys I immediately know. I have no idea (and I really don't want to know) how do you match a generic "end" with the corresponding block opener in Ruby.


    Do you think this is unimportant? If so, you aren't a professional programmer, and it's OK for you to use that toy language, Ruby. But if you do coding for a living you understand how important it is to get things right with the least effort. The time you waste fighting the Ruby syntax could be used to write more code.


    Once you really learn a language like Perl or C you stop worrying about that dreaded "more than one way to do things", because you find which is your preferred way and stick to it. Once you truly understand C pointers you start to appreciate the way they let you code more efficiently the type of real-world applications that textbooks cannot present for lack of space.


    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.

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Working...