System administration work should use any and every computer language available when appropriate. So why single out Perl for a book?
The answer to this question harkens back the to the very nature of system administration. Rémy Evard, a colleague and friend, once described the job of a system administrator like this: "On one side, you have a set of resources: computers, networks, software, etc. On the other side, you have a set of users with needs and projects--people who want to get work done. Our job is to bring these two sets together in the most optimal way possible, translating between the world of vague human needs and the technical world when necessary."
System administration is often a glue job; Perl is one of the best glue languages. Perl was being used for system administration work well before the World Wide Web came along with its voracious need for glue mechanisms.
Perl has several other things going for it from a system administration perspective:
It is clearly an offspring of the various Unix shells and the C language, tools many system administrators are comfortable using.
It is available on almost all modern operating systems. It does its best to present a consistent interface on each. This is important for multiplatform system administration.
It has excellent tools for text manipulation, database access, and network programming, three of the mainstays of the profession.
The core language can easily be extended through a carefully constructed module mechanism.
A large and dedicated community of users has poured countless hours into creating modules for virtually every task. Most of these modules are collected in an organized fashion (more on these collections in a moment). This community support can be very empowering.
It is just plain fun to program.
In the interest of full disclosure, it is important to note that Perl is not the answer to all of the world's problems. Sometimes it is not even the appropriate tool for system administration programming because:
Perl has a somewhat dicey object-oriented programming mechanism grafted on top of it. Python is much better in this regard.
Perl is not ubiquitous. You are more likely to find the Bourne shell than Perl on a system as it comes off the shelf.
Perl is not always simple or internally self-consistent and is chock full of arcania. Tcl has far fewer surprises.
Perl has enough power and esoterica to shoot you in the foot.
The moral here is choose the appropriate tool. More often than not, Perl has been that tool for me, and hence this book.
Copyright © 2001 O'Reilly & Associates. All rights reserved.