Minimal Perl for Unix and Linux People

Ravi writes "Perl (Practical Extraction and Report Language) — the language which was created by Larry Wall is arguably one of the greatest programming languages. But it has a reputation for taking an excessive cryptic nature which gives it an image especially among Perl novices as a language which is complex and hard to master. Minimal Perl: for Unix and Linux people, authored by Tim Maher and published by Manning Publications addresses the obstacles presented by Perl's complexity. This book which is divided into two parts comprising of a total of 12 chapters takes a unique methodology to explain the Perl syntax and its use. The author emphasizes on Perl's grep, awk and sed like features and relys on concepts such as inputs, filters and arguments to allow Unix users to directly apply their existing knowledge to the task of learning Perl." Read on for the rest of Ravi's review.

Minimal Perl for Unix and Linux People
author	Tim Maher
pages	464
publisher	Manning Publications
rating	8
reviewer	Ravi
ISBN	1932394508
summary	Provides a slice of Perl which when mastered can accomplish most of the jobs which require Perl

What I found while reading this book is that the "Minimal Perl" is a specially crafted subset of Perl language designed to be easily grasped by people who have a Unix background and who wish to use Perl to write their scripts. Its aim is to filter out the complex way of writing programs using Perl and whenever possible to accomplish tasks using just one or two lines of Perl. In the first part of the book, the author explains how Perl can be used to do the same tasks as accomplished by common Unix tools such as grep, awk, sed and find. He goes one step further by explaining how one can accomplish much more and in a much simpler way by using Perl techniques.

Throughout the book, the author makes sure that the learning curve in acquiring Perl skills remain gentle. Perl is a language whose syntax has a multitude of options, this book is peppered with numerous tables which provide excellent information at a glance. For example, in the third chapter titled "Perl as a (Better) grep command", the author lists and compares the fundamental capabilities of Perl and the different grep commands such as grep, egrep and fgrep which clearly shows the advantages that Perl has over grep. In another table, you get a birds eye view of the essential syntax of Perl's regular expressions and their meaning. This chapter alone has around 12 tables. This is a really nice feature because it doubles as a Perl reference where you can flip to the respective page and get the information you need.

The main strength and drawback of a language such as Perl is its dependence on regular expressions for accomplishing complex tasks. Once you master the regular expressions, the sky is the limit for ordering and segregating data using this language. In Perl, there is more than one way of doing the same thing. What is unique about this book is that the author specializes in explaining the easiest way of doing a particular task.

In many places, the author demonstrates complex tasks using just a few lines of Perl code. Many of the examples covered in this book are practical examples which give an idea of how the commands relate to the final outcome. For instance, while elaborating on the one line grep like commands in Perl, the author illustrates a web oriented application of pattern matching where he shows how to extract and list, the outline of slashdot.org site's front page. The surprising thing is this is accomplished using just a single line of Perl code. This book has lots of such one line examples which teache how to use Perl intelligently using minimal effort.

If part I of this book focuses on ways in which simple Perl programs can provide superior alternatives to standard Unix commands, the second part throws light on the other aspects of Perl concentrating on the syntax of the language and various built-in functions and modules available which do away with a lot of re-invention of the wheel, so to speak, and helps churn out code which is portable.

Chapter 7 titled "Built-in functions" introduces an eclectic mix of functions available in Perl. You have functions which are used to extract a list of fields from a string, functions to access the current date and time, generating random numbers, sorting lists, transforming lists, managing files with functions and so on. These functions are broadly classified into those which generate and process scalars and those that process lists.

In chapter 8 of this book, the author involves the reader on the numerous scripting techniques that can be used to write better Perl programs.

It was quite surprising that the author has chosen to discuss the variables, more specifically the list variables comprising of arrays and hashes, as well as the looping constructs only in the 9th and 10th chapters, when they should be somewhere up front. In hind sight, I feel it is a good decision. Once you execute the one liner Perl programs in the initial chapters, you will be fairly confident in using Perl by the time you reach the 9th chapter.

The last two chapters deal with creating sub-routines and modules. Over the years various Perl programmers have created modules which are used for diverse purposes. With an aim to share these modules, they are collected and stored at one central place known as CPAN, which is an acronym for Comprehensive Perl Archive Network. The final chapter, apart from teaching how to create modules in Perl and manage them, also introduces the CPAN and ways in which one can find the right module by searching on CPAN.

The special variables cheat-sheet and the guidelines for parenthesizing code provided in the two appendices are really useful as a quick reference while writing Perl programs.

This is not a comprehensive book on Perl, rather the author provides a slice of Perl which when mastered can accomplish most of the jobs which require Perl. You won't find object oriented concepts of Perl being mentioned in this book. In many ways the author has moved beyond explaining a subset of Perl by providing a section titled "Directions for further study" at the end of each chapter, where the author lists further material which can be used to learn more about the topic that is covered.

I really enjoyed going through this book, especially because of its focus on the practical side of using Perl and taking a minimal approach.

Ravi Kumar maintains a blog titled "All about Linux" where he shares his thoughts and experiences in using Linux, Open Source and Free software.

---

You can purchase Minimal Perl for Unix and Linux People from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Minimal Perl for Unix and Linux People

[mobby_6kl]

Minimal Perl for Unix and Linux People? Is this the result of a perlgolf competition between perl-related books?

Very Minimal Perl for Unix People

[Phreakiture]

Very useful if you need to use text files from DOS/Windows and DOX2UNIX is not installed:

perl -e "while(<>){s/\r//;print;}"

This strips carriage returns out of a file, and does it pretty quickly.

Re:

[torstenvl]

mv text.txt text.dos && cat text.dos | tr -d "\r" > text.txt && rm text.dos

Re:Very Minimal Perl for Unix People

[Tet]

This strips carriage returns out of a file, and does it pretty quickly.

No, it's horrendously slow. The traditional Unix way of doing it (tr -d '\015') is around twice as fast on files that are sufficiently large that startup costs are lost in the noise, and even faster on smaller files.

Re:

[jcuervo]

Shouldn't that be perl -pe 's/\r$//;'

What I love most about Perl is it's SPEED!

[clayne]

(yes I pre-ran them both multiple times to reduce cache affects)

[src] $ time perl -e '$tdata = "../../tests/ctok.in.2"; $sz = -s $tdata; print "sz == $sz\n"; open(FH, $tdata); while (<FH>) { @t=split(/[ :#]+/, $_); $c += $#t; } print "c == $#t\n";'
sz == 96252007
c == 12301001

real 0m31.877s
user 0m31.662s
sys 0m0.148s

[src] $ file ctok
ctok: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, not stripped
[src] $ time ./ctok ../../tests/ctok.in.2 " :#"
sz == 96252007
c == 1

*sigh*

[A beautiful mind]

Perl (Practical Extraction and Report Language)

That's a backronym. By those standards you could also call PHP Pretty Hellish Performance.

Re:*sigh*

[Timesprout]

Na, theres nothing pretty about PHP

Re:

[swordgeek]

Honestly, it doesn't matter. The cart came before the horse in this case, but regardless of its acronymic meaning (or lack thereof) when it was created, Perl DOES now stand for Practical Extraction and Report Language. Just ask Larry Wall.
Remeber that a "Backronym" (hate that word!) is a subtype of acronym.

Re:*sigh*

[croddy]

Steve Wilhite also tells us that "GIF" should be pronounced like "JIF". Don't let these erroneous claims fool you just because they come from the authors.

Re:

[pclminion]

Steve Wilhite also tells us that "GIF" should be pronounced like "JIF".

Which is exactly how everybody I know pronounces it.

Let me guess: when you say the word "laser," you pronounce the s with a "zzz" sound, right? Except the "S" in laser means "stimulated," not "ztimulated!" See, you're pronouncing laser wrong!

A more reasonable conclusion would be to say that the sound of a letter in the pronunciation of an acronym need not relate to the sound of that letter in the word from which it derives.

I've got a question about subtypes of acronym

[spun]

Remeber that a "Backronym" (hate that word!) is a subtype of acronym.

Would Muhammad Ali's GOAT (Greatest Of All Time) line of food products [bakeryandsnacks.com] be considered a snackronym or a blackronym?

Re:

[NoOneInParticular]

But, what happened to "Pathetically Eclectic Rubbish Lister"?

Re:

[Nefarious Wheel]

I thought it was "Perl Hates Programmers"?

Re:*sigh*

[grcumb]

Perl (Practical Extraction and Report Language)

That's a backronym. By those standards you could also call PHP Pretty Hellish Performance.

ITYM 'Poorly Hung Perl'. 8^)

Re:

[arivanov]

I like debian description better: $ dpkg --status perl-base | grep Description Description: The Pathologically Eclectic Rubbish Lister While at it, there is no such thing as minimal perl. It is the most addictive language I know. Once you are hooked, you are hooked. Seen it many times.

Cryptic? Complex!?

[setirw]

But it has a reputation for taking an excessive cryptic nature which gives it an image especially among Perl novices as a language which is complex and hard to master.

So wrong! Just look at the following example:

#!/usr/bin/perl -w

length q caller vec and print chr oct ord q qx eq and print chr ord q ref or and print chr ord q or no and print chr ord q else and print chr ord qq q q and print chr ord q tie gt and print chr ord qw q sin q and print chr ord q q eq and print chr ord qw q sin q and print chr ord q sin s and print chr ord q cmp lc and print chr ord q split s and print chr ord qw q lc q and print chr ord q ne sin and print chr hex length q q bless localtime ref q

Run that. Nothing cryptic or complex at all.

(BTW, it prints "Perl is simple!")

Re:Cryptic? Complex!?

[MoxFulder]

Run that. Nothing cryptic or complex at all.

Indeed! I used to be a die-hard hard-core Perl hacker. When I discovered Perl in college around 2001, I thought it was the greatest thing since sliced bread. And Perl really was revolutionary: you could do almost everything you could do in C, but more concisely, since you could create complex data structures without manual memory management.

I used Perl for fun and profit (wrote many Perl scripts for a speech software company) for many years, hanging on past the point where others started using Python, PHP, and Ruby instead. I knew Perl and could practically think in it. But one of the main problems with Perl is it's so easy to right totally unmaintainable, totally unreadable code. I read a Perl program I wrote a few years ago and I can never figure it out. The object-oriented part of Perl is a ridiculous kludge with so many little details that I can't remember them all. There are about 100 subtly different ways to write a constructor for your object:

sub new() {
    my ($class) = @_;
    my $self = {}
    return bless $self, $class
}

sub new() { return bless {} }

sub new() {
    my ($class) = @_
    my $self = {}
    bless $self, (ref $class || $class)
}

All of these, of course, have subtly different behaviors. The second will break inheritance. The third will allow you to use the constructor as an instance method, not just a class method. There are no enforced function prototypes or standard way to get parameters... and if you do use the *optional* prototype mechanism, you will subtly change the precedence of calls to your function.

I thought that having 1000 ways to do something was great, but it turns out to be a nightmare for non-trivial programs. Every time I try to use a cute fancy shortcut in Perl, it bites me in the ass. As a result of the over-flexibility, people have tried to impose "standards" on Perl. There are "standard" techniques for named parameters, "standard" techniques for accessor functions, etc. And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases (it's greatest strength!!!). And not all those modules use the standard techniques.

About a year ago I decided to give Python a try. And I haven't looked back. It can do everything Perl can do, and then some. Everything is clearer and having a "standard" way to do most things makes learning new modules immensely easier. Having slightly more verbose syntax and strict type-checking is slightly annoying at first, but keeps me sane in the long run.

Basically I don't use perl for anything other than one-liner regexp tricks anymore. Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the string FOO to BAR in all the files in the current directory.

Re:

[Ikoma Andy]

But one of the main problems with Perl is it's so easy to right totally unmaintainable...

Dude, I'm thinking it's not Perl that was your problem...

Re:

[MoxFulder]

Hehehe... ya got me! You know what's funny? I think that's the first time I've ever made that mistake. I'm a bit of a grammar Nazi normally. I'm off to do some self-flagellation now.

Re:Cryptic? Complex!?

[abigor]

His usage of "it's" is correct. It's = it is.

Re:

[VGPowerlord]

GP quoted the wrong it's.

And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases (it's greatest strength!!!)

Re:Cryptic? Complex!?

[massysett]

Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the string FOO to BAR in all the files in the current directory.

Sed will do that too:

sed -i 's/FOO/BAR/g' *

The review says that the book uses the reader's knowledge of sed, awk, and grep. I figure: why not just use sed, awk, and grep...however, one advantage for Perl here is that (I presume) that line works with any Perl; '-i' is a GNU sed extension and may not work on non-GNU seds...

Re:

[MoxFulder]

Sed will do that too:

sed -i 's/FOO/BAR/g' *

The review says that the book uses the reader's knowledge of sed, awk, and grep. I figure: why not just use sed, awk, and grep...however, one advantage for Perl here is that (I presume) that line works with any Perl; '-i' is a GNU sed extension and may not work on non-GNU seds...

Indeed, you're completely right! After 6+ years of using Perl, I no longer use it for anything that sed/awk/grep can't do :-P

As I've said, Perl was great while it lasted. It's just that t

Re:

[Scarblac]

I was a Python afficionado, although most of my professional experience was with Java. Then I joined a Perl project. I was open minded, any language can be good in the right hands. Now, two and a half years later, I'm pretty good at it.

As the team grows, we find ourselves relying more and more on standard techniques. They're not your standard techniques, they're just what we came up with as our standard way. They work well. We have a beautiful object oriented mod_perl/Template Toolkit system, unit tests, R

Strategies for complex perl code bases

[doom]

But then, note that objects are just hashes. Sometimes, you get odd data in them, due to some bug. Where did that happen? Of course you use grep, but there are so many ways to put something into a hash, that you run into problems. So you use getters and setters and make sure that all the code everywhere uses them.

That's a pretty common way of implementing objects in perl, but it is, of course, not the only way... The current thinking seems to be we should all switch to using "Inside-Out Objects" (briefly: object data is moved to class data, and the object only needs to be a unique id to pick out the correct values from the class data -- so you bless a scalar ref, and get a lightweight object which stringifies to a unique id). The point being that if you do things this way, you really *have* to use the accessors, you can't cheat and treat the object as a hash reference any more. Unfortunately, last I looked there was some argument about what precisely was the right way to do this (there's some issue with thread support), though the best publicized way of doing it certainly the one recommended by Damien Conway in his newish book "Perl Best Practices".

If you're not interested in re-writing your entire code-base to conform to someone's notion of "Best Practices", myself I might suggest looking into "lock_keys" in the Hash::Util module. You could adopt the practice of doing a lock_keys on the hashref at the end of the object/creation initialization stage, and then if anyone accidentally tries to create a new hash field later, it will throw an error. A simple, effective trick, and I wish it were better publicized...

On occasion I wonder how hard it would be to write an automated test that would look for cases where someone has done a "$obj->{hash_field}"...

In general, coding standards are important, and where the language is really flexible, they arguably become even more important -- but I think a lot of that problem can be solved with some good automated testing. For example, there's a CPAN module called Perl::Critic that will do things for you like check to make sure your code matches a given set of coding standards (it defaults to Conway's "Best Practices", as I remember it).

Re:

[Scarblac]

Thanks for the comments!

The idea of blessing a scalar as an index is new to me, an interesting concept. It's going to be hard to use that in any short time frame, but who knows, we might be able to refactor it in over time :-) I actually ordered the book recently, it hasn't arrived yet. I wasn't expecting anything special, but apparently I'm underestimating it.

As for Perl::Critic, I think I'm going to play with that tomorrow, sounds fun, never thought to look for something like it! Thanks!

PseudoHashing

[goombah99]

Another way to lock a set of keys that works at "compile" time rather than runtime (that is it works on the class and not the instance, is to use pseudohashes. This actually makes the code faster too. Effectively what it is doing is using an array rather than a hash and all the keys are like enums. But all that's hidden behind a layer of syntactic sugar so it looks just like a normal perl hash-based object.

Re:

[chromatic]

Actually, pseudohashes made everything slower, so they've been long deprecated and won't be in Perl 5.10.

Re:

[chromatic]

You could adopt the practice of doing a lock_keys on the hashref at the end of the object/creation initialization stage, and then if anyone accidentally tries to create a new hash field later, it will throw an error. A simple, effective trick, and I wish it were better publicized...

Hey, that's Perl Hack [oreilly.com] #87!

Re:

[MoxFulder]

But even things like renaming functions... different calling syntax can make it hard to grep for uses of a function, even. It's getting too ridiculous.

This was one of the things I noticed immediately when poking around in the Python standard library... it's quite easy to find where functions are called and defined. Just grep for "function\s*(" or "def function". It's always on one line. The parentheses are always there. It jumps out visually. Nice.

Our book of coding standards is getting so thick that w

Re:Cryptic? Complex!?

[jez9999]

If only Python didn't require the use of whitespace for defining blocks. It is indeed tragic that an otherwise fine language is so goddamn retarded in that one aspect.

Re:Cryptic? Complex!?

[MoxFulder]

If only Python didn't require the use of whitespace for defining blocks. It is indeed tragic that an otherwise fine language is so goddamn retarded in that one aspect.

You know, it seems like *everyone* is put off by this aspect of Python at first. The first time I looked at it, it drove me nuts, and then I ignored Python for another two years.

But once I actually tried to write a program in Python, I found I didn't mind it one bit. Within a few hours my eyes didn't get confused by the lack of braces. I think it's actually easier on the eyes once you get used to it.

So I can't say, "don't knock it", because I've done that myself for sure. But do give Python another look, maybe play around with the tutorial for an hour or two.

Re:

[TeknoHog]

But once I actually tried to write a program in Python, I found I didn't mind it one bit. Within a few hours my eyes didn't get confused by the lack of braces. I think it's actually easier on the eyes once you get used to it.

Python was one of my first programming languages, and the whitespace thing made sense to me from the beginning. In most C-style code, people use both braces and indentation to denote blocks; isn't that redundant? It seems braces are for the compiler and indentation is for human readers. Shouldn't higher level languages be designed for humans rather than machines?

Re:

[slittle]

You can't put more than 1 statement on the same line as an 'if' or 'else'. "if (increment_them) {a++; b++;}" won't fly.

You can (but generally shouldn't).

>>> if True: a = 0; b = 1; c = 2; print a, b, c
0 1 2
>>>

Re:

[Chris Burke]

About a year ago I decided to give Python a try. And I haven't looked back. It can do everything Perl can do, and then some. Everything is clearer and having a "standard" way to do most things makes learning new modules immensely easier. Having slightly more verbose syntax and strict type-checking is slightly annoying at first, but keeps me sane in the long run.

Basically I don't use perl for anything other than one-liner regexp tricks anymore. Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the st

Re:

[Coryoth]

Indeed, this is the only thing I mind about indentation in Python: it makes it hard to cut-and-paste code. Fortunately, Emacs has rectangle mode which I find very helpful in indenting a bunch of lines together all at once (C-x t SPACE SPACE SPACE SPACE ENTER to move them all 4 spaces forward, for example).

Hmm, that seems a round-about way to do things. I presume you never happened to run into some of the nice features in Emacs python-mode, specifically python-shift-left and python-shift-right which will mov

It gets worse...

[mkcmkc]

Even this

/$foo[bar]/

has no comprehensible meaning.

Perl could be the first language to bow out gracefully when it's day is done, but I'm not holding my breath...

Re:

[Millenniumman]

How do you avoid using regular expressions? What do you replace them with? And how can they be confused with binary?

Re:

[admdrew]

Well most languages have these things called functions, you can use them to do your own string functions.

Yay! Let's reinvent the wheel by writing 10, 20, or more lines of code for something regular expressions would be able to handle in one. Furthermore, let's claim this is done for the sake of keeping the code 'pretty,' because it's far too embarrassing to admit that we don't really understand how to use regular expressions!

Other Languages have a bunch of well performing string functions so I don't need

I {} Perl

[Cally]

perl has paid my rent and bought me more of the special, special tea from high in the Himalayas that enabled me to understand it so easily in the first place. I find myself speaking it in my sleep (and yes, you do speak Perl, just as you program in C.) It's a matter of some puzzlement to me that the loathesome homunculous that is PHP supplanted Perl as the preferred language for non-ASP web programming. (And ASP..? Don't get me started!!) I wrote my first code many years before discovering Perl, but it was Perl that turned me into a programmer. To me, you cannot claim to know Unix until you can read Perl (in both directions - in and out.)

That is all...

Re:I {} Perl

[timster]

"Speak" Perl, right. Because what Unix really needed was a combination of the specificity of natural language and the friendly syntax of awk.

Re:

[Phroggy]

It's a matter of some puzzlement to me that the loathesome homunculous that is PHP supplanted Perl as the preferred language for non-ASP web programming.

PHP is friendlier for beginners in two important ways: first, perl borrows heavily from existing C and UNIX syntax; anyone who already knows C and wants to calculate tomorrow's date will feel right at home with localtime(), but the newbie will find PHP's date functions far easier, for example. Also, perl's syntax is vastly more complex than PHP's, and language syntax isn't something you can just look up in a reference when you're not sure what something does. In PHP, once you learn the basics, anything

Re:

[Cally]

Yes, yes, yes, but don't distract me with these pettyfogging facts. The joy and euphoria I felt when I got over the lip of the curve and realised that I had the simple, simple key to parsing obfsucated C sig one-liners like yours just can't ever be found in PHP. Yes, PHP might make it easy to do the easy things, but there'll never be a PHP one-liner sig, because there's no joy in Perl.

the book looks very relevant

[keshto]

I use Python for most of my real scripting needs (i.e. any script that goes into a file and is over 10 lines long). I find Python to be a much easier language to think in and write. The biggest attraction of Perl for me is as a better awk and sed. Almost all of my Perl uses are of the sort "perl -pe 'xxxx'" . It seems the book is aimed at users like me.

Re:

[brunson]

Perl is the vise-grips of programming languages, and as my Dad always told me, "There's a right tool for every job and it's almost never vise-grips".

Should I read this or continue with sed/awk?

[RiotXIX]

Useful review.

I'm currently going through http://www.oreilly.com/catalog/sed2/ [oreilly.com], but I can see my using perl the more I do website programming. Would an experience scripter suggest that I switch to perl (for it seems it can perform similar text manipulation functions conveniently in a programming lanuage), or spend more time with sed/awk?

I'll probably do both incidentally, but opinions would be appreciated. It seems everyone rates perl.
I was going to switch to Python, but apparently Perl is better for smaller/one line regexp manipulation in scripts, and python for building large applications.

Comment removed

[account_deleted]

Comment removed based on user account deletion

That's fine

[RiotXIX]

No that's brilliant - thanks for your opinion. A lot of people are pushing me for python, but I always figured it's reveared status for text processing/manipulation & wealth of existing scripts/implementations would mean perl would win hands down.

But if it's possible to do these things with python, then I'll go for that (soley for the reason that certain people with opinions I respect say it's the new way forward). I don't want to waste my time focusing on two languages (learning perl, and then moving t

Re:

[doom]

CRCulver wrote:

I don't want to put Perl down, but I think that its day is past except for those who, because they learnt it when it was the only thing around, are willing to tolerate its eccentricities.

Oh come on, the reasons to stick with perl are (1) the huge code base available on CPAN and (2) the perl programming culture.

Perl culture is in great shape at the moment, in my opinion. The most annoying people in the world have all switched to Python, and the dull, money-grubbing bastards are all off

Re:Should I read this or continue with sed/awk?

[doom]

The most annoying people in the world have all switched to Python

Heh, I guess I'm one of the most annoying people in the world then. Are you sure it's not just that the grapes are probably sour anyway?

Well, I didn't mean that to be taken personally... but consider the fact that ESR is on your side.

Re:

[chromatic]

Because Perl is a general purpose programming language, it can do a lot more than sed or awk. Learning all three is useful if you do a lot of Unix administration or command-line work, but you can get by with Perl alone if you only learn one.

... apparently Perl is better for smaller/one line regexp manipulation in scripts, and python for building large applications.

It depends on the application. I appreciate perl2exe (though I've heard good things about PAR [cpan.org] and wxPython has better documentation than w

Re:

[tknd]

Yes and no.

I don't have much experience with sed and awk so I'm not sure what you plan on using perl for. The basic answer is you need to use the right tool for the job but I don't know what job you have so I can't directly answer your question.

Perl is pretty good with text manipulation due to it's built-in and extensive support of regular expressions. It's also got most programming language features so you can extend it and use it for larger tasks or even create real software all in perl. Perl also has a v

Re:

[Bluesman]

Like Java, the strength of Perl is in its libraries and its popularity. Unlike Java, Perl has support for a decent set of built in data structures, and the built in regular expression syntax is second to none.

Perl's greatest strength is CPAN, which is a library of perl modules that handle just about any programming task that you can think of, and then some. Sometimes, it's uncanny how well certain modules fit your problem -- you can almost guess the names based on what you want. (need to find the size of

Re:

[Tet]

Perl's greatest strength is CPAN

Perl's greatest weakness is CPAN, which makes deployment of perl code onto any halfway sane production server all but impossible.

Re:

[_|()|\|]

Would an experience scripter suggest that I switch to perl ... or spend more time with sed/awk?

There are two good reasons to learn sed and/or awk: portability and history. Although Perl may seem ubiquitous, you wouldn't use it in a cross-platform (i.e., Solaris, AIX, Tru64, HP-UX, etc.) install script. Since Perl is in some ways inspired by sed and awk, knowing them may help you to appreciate Perl. Otherwise, I wouldn't spend too much time on them.

Re:

[halivar]

you wouldn't use it in a cross-platform (i.e., Solaris, AIX, Tru64, HP-UX, etc.) install script

I've used it for just such a purpose, quite successfully. But I suppose it depends on the shop you're working with. In ours, we had the same version of Perl on all the Unix and Linux machines, so moving the scripts around was cake.

The shell scripts, on the other hand...

Re:

[clem.dickey]

I gave up sed and awk for perl because I grew tired of silly limitations: 2048 chars per line in sed, 300 chars per line and 300 fields in awk. Implementations could increase them, and probably have, but Perl avoids artificial limits as a matter of principal.

Nothing against Python though. I like the fact that the Python specification is about 80 pages, while the Perl specification is loosely spread throughout the 1000-page Camel book.

I wouldn't forget sed entirely. The Liinux Filesystem Hierarchy Standard r

Re:

[clem.dickey]

Should read *3000* characters per line in awk.

That's cheating

[Daishiman]

It's not considered one line if it has 3398EAFF23 characters.

Basic way to clean up your Perl code

[TheRealMindChild]

10 CurrentFile = Dir("*.pl") 20 Do while len(CurrentFile) > 0 30 Kill CurrentFile 40 CurrentFile = Dir() 50 Loop 60 End

Why not for Windows people?

[rrohbeck]

I think Windows folks need "Minimal Perl" a lot more.

Just remembering by boss's jaw drop when he asked me if I could do a quick analysis of a couple thousand lines of logs and asked how long it would take. "10 minutes." And I delivered. He thought I'd have to fire up VS and write some C code.

He borrowed my Camel book during his next vacation.

Re:

[SCHecklerX]

Good point.

All of the windows boxes where I used to work had activestate installed on them, and if I ever have a job where I am administering windows systems again, that will be my first addition if it is not already there.

Re:Why not for Windows people?

[Phroggy]

Have you tried Learning Perl on Win32 Systems [oreilly.com]? Windows users wouldn't benefit from the Minimal Perl approach, because they don't have the background it builds on. This book starts at the beginning.

Re:

[bean123456789]

I think your example is exactly why perl is so useful. For small, specific tasks that you may or may not ever need to repeat. I think for programs that will need maintenance it is a terrible language. Really it is the swiss army knife of languages and I'm glad that I learned it, but I would never write an involved script anymore.

Cryptic?

[locokamil]

Perl newbie here.

Is it just me, or is it possible to create perfectly legible code in Perl if you use good technique, just like in any other language?

The cryptic/convoluted stuff only comes out when you try to be too cute. ..

Re:Cryptic?

[drinkypoo]

Is it just me, or is it possible to create perfectly legible code in Perl if you use good technique, just like in any other language?

Of course. The thing that people complain about is that perl allows you to write code that only a fellow perl-head can understand. It's harder to accomplish that with C, for example. But perl doesn't automatically mean you won't understand it. It just makes it more likely :)

Re:

[abigor]

Sadly, depending on people to behave well doesn't work, particularly in large projects. That's just life, I guess. Languages that enforce legibility (Python is great for that) lead to lower maintenance costs in the long run. And it's all about the bottom line.

Cryptic whitespace

[myowntrueself]

Languages that enforce legibility (Python is great for that)

A language which makes a semantic distinction between tabs and spaces may give the appearance of enforcing legibility but in fact does little useful to help legibility.

A programming language should not make a distinction on meaning based on whether tabs or spaces are used; all whitespace should be regarded equaly (except, understandably, end of line characters).

Otherwise, python seems ok. I just wish it had a whitespace-agnostic mode.

*I* cannot visualy tell the difference between tabs and spaces, why should the programming language?

Re:

[abigor]

No, the whitespace enforces legibility when you have a team of 20 people working on the same code. It makes reviews and maintainence go smoothly. The code looks the same. You might have a theoretical issue with it, but in practise it works well and gets working code out the door quickly, which is all that counts, period.

Until something happens to the code, yes

[Wee]

No, the whitespace enforces legibility when you have a team of 20 people working on the same code. It makes reviews and maintainence go smoothly. The code looks the same. You might have a theoretical issue with it, but in practise it works well and gets working code out the door quickly, which is all that counts, period.

The problem I have with python (other than the lack of autovivication and CPAN) is that the whitespace can almost be thought of as non-portable metadata. The minute someone tries to past

Re:

[Prof.Phreak]

Cryptic perl is a myth. It's only cryptic if you don't understand it (or if things aren't indented properly).

Whenever I come across code that just looks like `an explosion at an ascii factory', I first indent it (which usually fixes the readability). If that doesn't work, I try to figure out what it's trying to do (likely developer didn't know any better, and used some clunky code to do something trivial; usually code that can easily be `clarified' by replacing whole sections of it with a single regex).

Perl

Re:Cryptic?

[stefanlasiewski]

Cryptic perl is a myth. It's only cryptic if you don't understand it.

Cryptic 32-character hexadecimal MD5 hashes are a myth. It's only cryptic if you don't understand it.

Re:

[qwijibo]

I think the majority of problems people have with Perl is when they want to learn Perl but have no interest in regular expressions. A 30 line program with a few non-trivial regular expressions looks deceptively simple, but is performing the job of a program that would be several thousand lines of code without the regular expressions.

Based on my own experience, I think management frequently drives the impression that perl code is unmanageable. I have had several occurrences where proof of concept code (lik

Re:

[zero1101]

Perl newbie here. Is it just me, or is it possible to create perfectly legible code in Perl if you use good technique, just like in any other language? The cryptic/convoluted stuff only comes out when you try to be too cute. ..

You're basically right. The problem is that when you've been writing Perl for a while, the shortcuts and such start to come naturally. It's not that the programmer is trying to be cute, but that the weird, unnatural-looking Perl constructs actually flow more logically once you're used to them. So while it's easier for a non-Perl programmer to read:

foreach $foo (@bar) {
if($foo) {
print $foo;
}
}

writing something like that would be painful for a Perl programmer. (Sorry, can't seem to get my indents t

Re:

[locokamil]

Actually, that one threw me the first time I saw it... although I find that if you throw in a "use strict" in your code, it forces you to scope your variables properly, and thus drives home what the code is attempting to do more clearly.

Not hard to learn, very easy to remember

[SCHecklerX]

The only 'strange' thing with Perl is its use of symbols to denote things. That is not really that big of a deal, and in fact makes working with code a bit easier, IMO, since you know loosely what type a variable is just by looking at it and the context of the code that surrounds it.

The thing I've noticed, as a Perl programmer, is that it is the *only* language I've ever used (amongst bash, c, c++, java, rexx, fortran, basic) that I can take a break from for a year, come back, and be able to write a simple script without the need to refer to any books or online manuals. That is VERY useful for those of us who are more sysadmins than programmers. This power is partly due to the "more than one way to do it" philosophy, that lets you program in a style that works for you, hence allowing you to remember *how* to write in that language.

Then again, that's what most anti-Perl folks bitch about. Any language can be obfuscated. If you write hard to decipher code in Perl, you'll write it that way in any language.

Re:

[quintesse]

"without the need to refer to any books or online manuals

That might be true for you, maybe you've got some kind of photographic memory but for me it's 100x times easier to come back to a language that just says Map things instead of trying to remember what kind of variable %things is exactly. (NB: Had to google for the % symbol, thought it was @ for maps actually, see?)

Re:

[goombah99]

I have noticed the same. it's the one language that sticks with me despite breaks. And anything I forget is in the man pages in plain english not to auto-matically generated document.

Rexx

[LeninZhiv]

Perl was long my scripting language of choice until I discovered Rexx, which to me has a very similar feel and philosophy, but is much easier to retain the whole syntax of, and (the big winner) *much* easier to reread a month later.

Of course, Rexx is not an *it* language, but even Perl seems to be waning in favour of Python and Ruby, so I'll take the risk in bringing it up even if it isn't something we're 'supposed to be' excited about. As if a robust and mature scripting language were a bad thing...

Re:

[LMacG]

Just out of curiousity, what environment are you using Rexx in? I wrote some pretty bitchin' REXX scripts on OS/2 back in the day.

Re:

[LeninZhiv]

Regina on Linux is my current weapon of choice. (Perl and Unix really do fit hand-in-glove in some ways, but Rexx is so easy to use and so easy to remember that I think it adapts really well to the Unix/Linux world*, even if it isn't 'native' to the platform's culture.) Not to diss hard-core Perl hackers, but for people who only occasionally have recource to a scripting language yet don't want to sacrifice power I think Rexx is a real win.

* So long as you are open-minded enough that you can get used to so

Picking Up Perl

[nbritton]

This: http://www.ebb.org/PickingUpPerl/pickingUpPerl.pdf [ebb.org] guide is awesome if you want to learn Perl. Concise and articulate, it manages to explain all the major topics of Perl in 66 pages. I recommend working through the entire guide as quick as possible, don't worry about remembering everything as you can always come back to it later. I also recommend having the O'Reilly camel books (Learning Perl, Programming Perl, Perl Cookbook) handy when going through the guide. You can read the books here: http://www.jimsannex.com/Studies/CD_perl/index.htm [jimsannex.com] but you better go out and buy the real thing, worth every penny!!! If your running Windows you'll need to download Perl and a good editor with syntax highlighting:

http://downloads.activestate.com/ActivePerl/Window s/5.8/ActivePerl-5.8.8.820-MSWin32-x86-274739.msi [activestate.com]
http://www.crimsoneditor.com/ [crimsoneditor.com]

After you install perl open a command prompt and run ppm, this is your simple GUI gateway to CPAN packages (make a mental note). After you get a handle on basic perl checkout Perl/Tk (GUI Toolkit for Perl). The Tk packages are included and installed with ActivePerl... Here's your first Perl/TK program:

use Tk;
my $top = new MainWindow;
$top->configure(-title=>"My First Perl GUI Program");
my $lab = $top->Label(-textvariable=>\$labelText);
my $b = $top->Button(-text=>'Click Me!', -command=>sub {$labelText="Congratulations! it worked!" });
$lab->grid(-row=>0, -column=>0);
$b->grid(-row=>1, -column=>0);
MainLoop;

Perl grepping is *slow*

[massysett]

different grep commands such as grep, egrep and fgrep which clearly shows the advantages that Perl has over grep.

I wonder if the author listed a significant disadvantage of Perl: it is very slow [swtch.com] compared to awk and grep. For example: "Notice that Perl requires over sixty seconds to match a 29-character string. The other approach, [used by grep and awk], requires twenty microseconds to match the string. That's not a typo."

There's nothing like specialized Unix utilities, refined over thirty years with some GN

Re:

[stu42j]

I recently switched to a grep replacement written in Perl [petdance.com] for most of my code searching needs and can't tell the difference in speed. More importantly, the time it saves ME by doing what I mean is more than worth the additional cpu time required by the computer.

perl5 has run it's course

[mo]

I've been programming perl for 10 years. I've written enough XS modules to be sadly familiar with perlguts and perlapi. I've used perl for a huge array of applications, not excluding some pretty twisted apache hacks using mod_perl. I write perl code every day in my job.

Lately however, I've grown more and more frustrated with this language. Here's some reasons why:

muddled standard library

While CPAN's depth has been a model for many programming languages to come after perl, it's anarchy kills me. The number of different CPAN modules to deal with time/date manipulation is silly. Newer languages have had the luxury of much more structured standard libraries that make much more sense as a whole.

object oriented perl is a hack

It may be possible that some very disciplined group of perl programmers have achieved that holy grail of pure OO perl in such a manner that the benefits of OO programming are available to them. In real life, most OO perl programmers are bombarded with example code, third party modules, and CPAN modules that are not OO. Because of this, most perl code falls back on it's procedural roots out of frustration. You can blame this on the programmers, but this doesn't happen nearly as much in Ruby or Python.

lack of modern frameworks

I'm still waiting for Rails or Django for perl. Catalyst is nice, but a bit disparate, and it just doesn't have the traction or the cohesion that the first-class frameworks do. It used to be that all the cool stuff was done in perl first (example: mod_perl). This isn't the case anymore.

bindings for other languages are no longer hard to find

It used to be that every cool project/library would only come with perl bindings. Stuff like mod_perl or perl-magick were all you got. These days, however, bindings for other languages are almost just as pervasive, and often better written. For example, the perl AGI bindings in Asterisk PBX aren't nearly as well done or supported as the bindings in other languages.

minnie pearl

[trb]

It's about time Minnie Pearl got some attention around here.

http://en.wikipedia.org/wiki/Minnie_Pearl [wikipedia.org]

Re:PERL backronym

[morgan_greywolf]

Nope.

Stands for Python'll Eventually Replace this Language.

or, optionally:

Perl Eats Ruby for Lunch :-D

Re:So you like the book

[realmolo]

8/10 is a *good* review. You've been reading too many IGN game reviews.

IGN scoring works like this:

5/10 - The game runs

6/10 - The game is an FPS

7/10 - The game has team-based mulitplayer online play

8/10 - The game runs at 190 frames-per-second

9/10 - The game is made by a publisher that buys advertising on IGN

10/10 - The game is made by a publisher that buys A LOT of advertising on IGN
 

Re:

[quintesse]

That's silly, it would not give you any opportunity anymore to give higher notes. Imagine that you can't find any flaws in the book, according to you that means he would have to give it a 10. Then next week another book comes out that is way better in lots of aspects.... what to do now? Give it an 11?

Writing book reviews is not an exact science, you can hardly make some kind of formula and get a meaningful result, so maybe what he uses is something like this (just an example):

4 - book contains incorrect inf

Perl Scripting for the Dummy Like Me (fixed)

[andy314159pi]

#!/usr/bin/perl -w
##Oh boy I'm using an advanced scripting language!
system("/usr/local/bin/csh csh.script_1");
system("/bin/rm /home/me/file_to_be_removed");
system("/usr/local/bin/application & application_output ");
system("/usr/local/bin/csh csh.script_2");
#
system("/bin/cat "I know Perl" > resume.txt");
exit

Re:

[Phillup]

You don't eat or drink or mow the lawn;
You just type on Slashdot all day long.

And then one day... you learn how to format and preview.

Re:

[halivar]

Them's fightin' words! If I PEEK and POKE enough, I could probably hack your box and fry your monitor!

And I'll do it without line numbers! Fear me!

Re:

[Goaway]

Nice list of languages nobody uses there.

Re:

[ForumTroll]

Not that I completely agree with the grand parent post, but who cares if they aren't main stream languages that are in extremely heavy use? PHP is a language lots of people use and it's a total piece of shit. Sure, Haskell, OCaml, Lisp etc. might not be used for writing the majority of simplistic CRUD web applications, but all of the languages the grand parent mentioned are seeing use in some of the more interesting areas of programming. For example, lots of the really interesting AI research right now i

Re:

[SCHecklerX]

Perl's "TMTWWTDI" actually DOES keep it simple. It allows you to adapt a specific style, and consistently use it.

Perl is the only language I have used that I can walk away from for a year, and then use it again WITHOUT having to touch a book or online manual.

What, exactly, does Perl's use of non-text characters have to do with consistency? BTW, ever try to write C code without (){}+=-*? Thought so.

Re:

[Fahrenheit 450]

I'd guess that it is one of the greatest languages in the same sense that McDonald's is one of the greatest restaurants.

Re:oh come on, you're not even trying now

[fireboy1919]

You're not looking at it right.

KISS is hard. Very hard. It's different in different places. Sometimes keeping it simple means writing less code. Sometimes it means creating a new sub-language that better describes your problem.

In perl, you can change the nature of the language itself. *Everything* can be changed. The idea is that if there is more than one way to do it, then you can do it the simplest way for whatever definition of simple is required.

Maintaining consistency is up to the developer himself. Obviously, those tempted to succumb to the lure of sloppiness (which, unfortunately, in my experience, is every perl programmer I've ever met including myself) shouldn't use perl for really big projects.
You can't blame the language for giving you that freedom, though.

Perl is where it is because you don't have to change the way that you think in order to program in it. Perl will change how it works to match how you think, which makes it more convenient than almost any other language.

That particular behavior is what makes it possible to have so many perl modules in existane, which in turn is responsible for the popularity. It's also why about half of those modules have bugs so horrible that they're unusable. It's certainly a tradeoff.

Re:

[qwijibo]

I would argue that the majority of business people hiring programmers to work cannot tell the difference between a well designed solution and a horrible kludge. The horrible kludge will always take less time in the short term than the well designed solution. Business people have no long term memory and only acknowledge short term goals. A horrible kludge is a cost effective short term solution.

Therefore, one can reasonably conclude that in many environments, Perl is an ideal tool for the problem at hand.

Re:

[doom]

If I'm well skilled in BASH plus sed and awk, what does perl buy me?

1. You immediately get some efficiency gains in the form of code run times, because you're not using six processes every time you turn around;
2. Having everything inside the one process means the pieces can all talk to each other easily (you're never stuck trying to figure out how to get a piece of data jump from one part of a chain of pipes to another);
3. Perl regular expressions are very powerful compared to the existing tools, and once you g