Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Introduction to Perl for Unix System Administrators

(Perl without OO and excessive complexity)

by Dr Nikolai Bezroukov


Foreword

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 different from other, often enthusiastic, books on Perl  -- I presuppose that Perl is a complex language that is difficult to master. some language features are treated with skepticism they deserve. We should try to write in it as simply as possible and do our best not to fall into over complexity trap that some Perl gurus advocate.  For example 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 couse and of course cannot cover all the langage. 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 even if he/she is an accomplished programmer in other languages. do not expect becoming 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 with 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.

Both system administrators and Internet Security Analysts often poorly understand systems that they need to protect. That means that one of the major task in improving security is to increase the level of the comprehension of the system that we need to protect. Perl is a great source of tools that can improve your understanding of the system. 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 (that I call Eastern Orthodox editors -- EOE). These underappreciated tools have important advantages over alternatives.

Intended Audience

The main audience for the book are students in the former USSR region and Eastern Europe who often do not have access to the latest and greatest printed books on Perl and sometimes even do not have access to books with WEB texts that are freely available on the Internet. Nevertheless, I used it in my teaching in the USA and have received positive references from many US readers.

This book was written for a one semester course at the universities and as an introductory textbook for self-study. The volume of material should be enough for 16 lectures course and less important from my point parts are just mentioned or not covered at all. I cannot and will not compete with publishing houses that produce rather comprehensive volumes 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.

If you try to compare this course with printed books generally 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.

The first five 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. There is a minor security-related bias, but it should not distract from the content and in fact there is not much space for such a bias in the introductory book. Still, some aspects of Perl that are relevant to security analysts like file systems attributes checking, are covered in more details than usual. Object oriented features and references are omitted as I do not consider them to be appropriate for an introduction to Perl.

I have tried to avoid overusing Perl jargon and to use common computer science terms whenever possible.  However  a lot of it is present (interpolation, scalar context, hash, etc.) because learning of Perl jargon is an essential part of learning the language.

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 and what pitfalls a novice should avoid. In this sense, the book is very different from O'Reilly Perl books. To a certain extent it is the complete opposite of 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 nessesary 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. 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 costructs better suitable for the job. For example, excessive usage of $_ (so called Perl default variable) is avoided.

Feedback

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

 Acknowledgments

I would like to thank Leonid Pauzner <leonid@pauzner2.mccme.ru> for corrections for versions 0.1 and 0.2 of the Chapter 2 and Chapter 3 of the book.


Webliography


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: Saturday, November 08, 2008