Teach Yourself PERL in 21 Days

 in
Don't let the size of the book intimidate you, though, it's due not to the complexity of the language, but to the easygoing writing style of the author.
  • Author: David Till

  • Publisher: Sams Publishing

  • ISBN: 0-672-30586-0

  • Price: 29.99 USA/39.99 CAN

  • Reviewer: David Flood

The 846 pages of Teach Yourself Perl In 21 Days from Sams Publishing—two inches thick—are intimidating. Don't let the size of the book intimidate you, though, it's due not to the complexity of the language, but to the easygoing writing style of the author.

The book is divided into 21 days (chapters) of differing length, three review sections (at the end of each “week”), several appendixes, and a thorough index. Each “day” has a discussion of a part of the language, examples (either complete programs or code fragments), warnings, sections of “Do's and Don'ts,” and questions or problems at the end. Suggested answers to each “day's” questions are supplied in an appendix.

I started reading this book with no previous exposure to PERL; by the end of the second week I was beginning to see places where the language might be used in real world applications. The examples and discussions were clear and easy to follow. After completing the book, I started writing a simple application; so far I've been able to do everything in PERL that I need to do.

Some of the functions of PERL are also directly translatable to other programs. The discussion of Pattern Matching (Day 7) should be (with author/publisher permission) incorporated into the sed manual page; I'd never been able to get sed to do what I wanted until I read this chapter.

However, the copy of the book I received had a few problems. It was from the first printing and had several errors that the proofreaders had missed. Some of those early in the book would trip up new users of computers. For example, in the section on ftping the PERL file to install PERL on the reader's machine, a sample ftp session is presented. In the sample dialogue, the GET command wasn't followed by a file name: get . When I tried this, ftp told me I needed to supply a file name. I knew enough to do a ls p* to find the current file and then type get filename to get it. (I only did the ftp session to test the directions, since I had already installed PERL from my Slackware CD-ROM.)

Another hazard lies in the discussion of the required first line of a PERL program #!/usr/local/bin/perl. There is a small discussion of the fact that it must be the correct path of the PERL interpreter, but the only advice given is to talk to your System Administrator. Since several folks are their own System Administrator, this might cause problems. Since there are already “Unix Only” discussions in some of the chapters, a small discussion of the which command would be a welcome addition.

I was able to detect at least one error for every two chapters. Upon requesting an errata sheet from the publisher via their area on CompuServe (which they advertise in the book), I was informed that they would get back to me. A week later, they still hadn't. Since files containing errata for some of their other books are available from the area, I presume that the book is still too new for a sheet to have been compiled.

The only other problem that I have with the book is its classification of “User Level: Beginning—Intermediate.” Since I have taken classes in both C and Ada, I was able to relate some of the concepts that I had learned to this language. However, as I pointed out before, some of the ideas presented are definitely not for beginning computer users.

Generally, I would recommend this book for any person who wants to learn PERL. But this is not the book for a person who is attempting to learn a first programming language.

David Flood is currently a student in the School of Drama at the University of Washington. He plans to graduate sometime in 1996 and to get a real job. He is reachable (for now) at dcflood@u.washington.edu.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState