May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Softpanorama Bulletin
Vol 23, No.01 (January, 2011)

Prev | Contents | Next

Foreword to Perl for system administrators ebook
Bulletin 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Jan Feb Mar Apr May Jun Jul Sept Oct Nov Dec

Foreword to Perl for system administrators ebook

This book is dedicated to the creators
of IBM PL/1 debugging and optimizing compilers,
the two greatest compilers that I've ever seen

This book is the result of conversion to ebook form of lecture notes that I used to teach Perl Unix administrators as part of corporate training program as well as students at FDU ( a one semester intro course). It is far from being perfect but still it is substantially different in its approach then from other Perl books. I see three main differences:

  1. Usage of Perl 5.10 exclusively. Many good books exist for Perl 5.6 ( released in 2000) and 5.8 (released in 2002). But for Perl 5.10 only a half-dozen books were published because this version was released when Perl popularity was on substantial decline, especially book-wise. It is not longer fashionable language despite the fact that it is the only scripting language installed by default on major Unix platforms. So while there are abundance of good Perl book there not that many books that use 5.10.
  2. It considers Perl as a better Unix shell and natural step forward for those who know shell.  Perl definitely  has the highest level of  Unix integration among scripting languages and for  system administrators who are by definition are not professional programmers and usually just know some elements of shell programming it is the easiest step forward as large subset of Perl is just "better shell then shell".  It also has a lot of interesting feature such as rich set of built-in functions, namespaces, (limited) support of coroutines (in open statement only). The only two areas where Perl is weaker in comparison with shell is that it lucks support of named constants (read-only variables), has worse level of support of coroutines. 
  3. It takes into account that the complexity of the language is excessive. That distinguish this book from many O'Reilly titles. Perl developers fight a difficult battle with limited resources. Perl is a complex language that is difficult to master and difficult to maintain. Perl is also a perfect example of a programming language that is larger then human abilities: it is simply impossible for a human  to remember all the language constructs, so everybody uses some subset of Perl, not the whole language.  Similar situation happened with other languages such as PL/1. 

    Moreover without constant use even important features of the complex non-orthogonal language are forgotten.  At the same time complexity of Perl reflects the complexity of the Unix environment. So to a certain extent it is unavoidable. It can be pushed into libraries as in C or in classes like in Java, but it is still present. You have two choices:

    I think that putting it in the language is more honest approach.

  4. While this ebook is sufficiently self-contained it presuppose the existence of several good free eBooks (that cover larger subset of Perl) and that students have them available for reference and use during the study. Among them:
    As initially this was lecture notes to my lectures there is also implicit "course book" that greatly influence content. Initially it was Perl Developer's Guide  by Edward S. Peschko and Michelle DeWolfe.  In the current version I suppose that students also own  Effective Perl Programming

  5. Some Perl features are not relevant for system administrators (OO is one example) are omitted and some are treated with skepticism they deserve. Not everything in Perl 5 is useful for system administrators. And in places which are important sometimes the language itself is pretty  raw as you can see from rules of using build in variables like $_, differences between string functions and array functions, etc.
  6. Conscious effort to avoid overcomplexity. There is even special class of Perl overcomplexity junkies among Perl books writers, who enjoy explaining esoteric features and publish incomprehensible scripts claiming that they are valuable Perl idioms. Such an approach in the long run undermine Perl, not popularize it. The difference between a good book and bad book is that good book makes complex things understandable, while a bad book makes incomprehensible even simple things. This notice is fully applicable to a special subclass of "complexity junkies" called "OO junkies" -- authors who assume that OO is the best thing in programming sense sliced bread and try to write each and every program in "OO fashion". In my opinion OO does not have value in writing Unix system administrative scripts, unless they use GUI and as such can be safely omitted from the introductory books. It a person needs it there are good books which try to explain it more or less clearly.  It is so important to avoid overcomplexity in teaching Perl that some sacrifices need to be made. Trying to teach too much Perl is the typical trap into which most Perl books authors commonly fall. That's why Perl is often hated by students.

    We should try to write in it as simply as possible and do our best not to fall into over complexity trap that many Perl gurus practice.  For example, in most (but definitely not all) cases OO style in Perl is more curiosity that a real tool that can get productivity gains: Perl is a little bit too high level language for OO ;-).

    I try to expose both the strong features of Perl and its weak points and inconsistencies. Flaws of Perl as a complex non-orthogonal language similar to PL/1 are openly discussed. This set of lectures is designed for one semester course and of course cannot cover all the language. But we will try to cover most interesting and important part. Exam is open book, lab based and  with 50% of tasks devoted to debugging prewritten Perl programs.  Komodo is used as IDE.

I am convinced that there is no royal road to language mastery. The more different your background from the language you need to learn, the more time you need and the more difficulties you will encounter. Generally, any user of a new programming language suffers a lot . Do not expect becoming a Perl expert in one semester.

Perl debugging represents another challenging problem. The quality of the debugger is good, but still it is a free open source implementation and as such it is limited to command line. The debugger's command-line history mechanism provides command-line editing like many shells, but you need correct build of Perl interpreter to enjoy this (you can also execute previous lines using exclamation point syntax). 

Also Perl is very high level language and to understand to what part of the program you should attribute a particular error message is rather hard in the current Perl implementation. Here recommendations of the famous book How to Solve It are directly applicable and I highly recommend it for any Perl student.

I also do not consider Perl to be a Unix bound, even in a philosophical sense (we will discuss this in Chapter 1 in more detail). Actually Perl is a very portable language and this is an important advantage.

System administrators often poorly understand systems there are assigned to administer. That means that one of the major task is to increase the level of the comprehension of the system.

Perl is a great source of tools that can improve your understanding of Unix. Moreover you can adapt these tools to your particular situation, making them much more useful. Here Perl really shines.  Although it's not connected with this book, I also  highly recommend to use Orthodox File Managers, also called Norton Commander-style file managers and XEDIT-style folding editors (which I call Eastern Orthodox editors -- EOE). These underappreciated tools have important advantages over alternatives and can be productively used with Perl.

Intended Audience

I hope that it will be useful for self-study for Unix system administrators who want to learn Perl in addition to shell. The first seven chapters also may be suitable for such courses  as "An Introduction to E-commerce", "CGI programming" and other courses that need a short introduction to the language. This is just an introduction and does not try to cover advanced topics. But material is presented in a "kiss" way with the distinct attempt to present Perl as a simple, logical language for writing system administration scripts.

Systems administrators need to deal with many repetitive task in a complex, changing environment which often includes several different flavors of Unix. Perl is the only scripting language which now is included in all major Unix flavors. That means that it provides the simplest way to automate recurring tasks on multiple platforms. Among typical tasks which sysadmin need to deal with:

The volume of material should also be enough for a standard, one semester 16 lectures course.

Less important for beginners parts of the language are omitted and that his an important difference with rather comprehensive volumes published under the disguise of a beginner course (like Beginning Perl from Wrox ;-). Again this is just skeptical introduction to the language suitable for one semester course nothing more nothing less.  Commercial five days courses covers approximately the same amount of material.

The book presuppose some level of familiarity with shell and Unix. The operating system that is used in examples is Linux.

It can be considered to be an attempt to provide a short introduction to Perl that can serve as a replacement of the O'Reilly's book Learning Perl: historically important, but outdated book that many still try to use as their first Perl book. Although the content generally corresponds to the content of Learning Perl, the structure of the books is different and more modern. Decisions on what additional features to include and what to exclude were partially dictated by the features used in typical security-related Perl scripts.

I would like to stress it again that overcomplexity and attempt to present author erudition in knowing some exotic language features is avoided as much as possible. This is probably the most important difference from other available Perl eBooks, most of which fall into "overcomplexity trap". Again Perl is example of the language that is too big for a single human to learn in full. So anybody, even Perl "overcomplexity junkies" are using some subset.

The author is not a native English speaker and for him grammar errors are completely natural in every way ;-). Those, who think that it might distract him/her, do not need to read any further.  The book is not free from typos either and readers with low tolerance for typos would do better by finding another book.  If you can forgive me these two weaknesses, you probably can benefit from the book.

I concentrated on how to use the language in Unix environment and what pitfalls a novice should avoid. In this sense, the book is very different from the typical  "O'Reilly Perl books" approach to the language. It does not consider Perl the best thing since sliced bread. I believe that other scripting languages can be better in some respects than Perl: TCL is definitely better if you are writing a program that needs an imbedded scripting language, PHP as server-side HTML imbedded language, etc. But you have only one head and sometimes it make sense to use Perl in areas that are not optimal for this particular language. Sometimes I also discuss compromises adopted during its design and possible other solutions in lexic and syntax. I assume that the reader knows something about programming, and that the reader understands fundamental concepts of how programs work. so while this is an introduction to Perl it is not an introduction to programming. I assume that the reader knows at least one traditional compiled language like C, Pascal, C++, etc. Programming experience in a high-level language is necessary for the understanding of the content outside the first chapter and neither this nor Perl in general should be used an introduction to programming.

How This Book is Organized

This book uses a two-stage approach to the language. Perl 5.10 is used.  Chapter 2 provides a brief overview of key concepts, and later chapters expand from the material presented in Chapter 2. This book also acknowledges the existence of other books on Perl and the fact that some of them are even better than this limited effort.

You should not rely on this book alone.  Generally you can do better by using it along with other books that may explain some parts of the language in more clear or suitable for your background way. As a minimum you should also read and use documentation provided with Perl distribution.

 You should not rely on this book alone.  Generally you can do better by using it along with other books that may explain some parts of the language in more clear or suitable for your background way. As a minimum you should also read and use documentation provided with Perl distribution.

E-text form used for this book gives and important advantage of providing hypertext references directly in the text. Many references to the Perl documentation are provided in each chapter of the book. Please use them and read corresponding parts of Perl documentation. For discussion of other Perl books see my BookGuide/Perl bookshelf page.   A lot of useful links are provided in Softpanorama University Perl page

Regular expressions (regex) are introduced rather late (chapter 5) and the content does not revolve around regular expressions as a central feature of Perl. Yes, regular expressions are useful and powerful tool. But  I feel regex and regex-based pattern matching should not be stressed in early chapters -- this is a difficult area where debuggers can be of little help. Regular expressions are a dangerous tool and it's very easy to shoot yourself in the foot if you are not extremely cautious.

Procedural string handling mechanisms in Perl are more or less adequate and less error prone for many Internet-related tasks and are much easier for beginners to debug. That's why I decided to introduce string functions in more detail than is usually covered in introductory books.

Generally, I tried to explain the limits of the applicability of short idioms that require time to get used to and that contain hidden shortcomings which overweigh their short length. But I did try to show common idioms that are in wide use, even if I personally am against a particular construct because of underlying problems. Here I would like to distinguish three types of scripts that are written in Perl:

  1. One time scripts (throw away) . Here one can cut corners to make them as short as possible, but one needs to remember that  short is not always good and nothing is more permanent than a temporary solution.

  2. Individual scripts to enhance your productivity -- these should provide the possibility of modification without undue effort by the original author. The quality of user input checking and diagnostics are not as important as simplicity and fitness for a particular purpose. Security issues can probably be ignored in most cases.

  3. Production scripts and scripts that can be accessed by external users (i.e. CGI scripts and Unix hardening scripts) -- here one needs to write scripts, or, more often, to modify an existing one,  in such a way that it will thoroughly check user input, provide useful error diagnostics in case of errors and not use features that can compromise the security of the system like direct calling of batch files, etc.

Those three types of scripts often require different programming solutions and for the third type avoiding some popular idioms is a recommended strategy. I usually am not too concerned with the minimization of the length of the script for the sake of minimization and do not consider shorter scripts necessarily better that longer ones, unless this is a better algorithmic solution or use language constructs better suitable for the job. For example, excessive usage of $_ (so called Perl default variable) is avoided.


I would appreciate any help in improving content and pointing out errors.


This ebook was derived from lecture Nikolai Bezroukov lecture notes at FDU. Lectures were based on the book Perl Developer's Guide  by Edward S. Peschko and Michelle DeWolfe. This is a Perl 5.6 book so it is now outdated. But this is a good book and influence of this book is very noticeable in this etext.

There are two good free Perl eBooks by David Medinets and Simon Cozens that the author used as complementary books for the course (mainly as a source of examples):

Some example are taken from those books.

I would like to thank Leonid Pauzner <[email protected]> for corrections for versions 0.1 and 0.2 of the Chapter 2 and Chapter 3 of the book.


Prev | Up | Contents | Down | Next




Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: Tuesday, March 12, 2019