[Courses] [Perl] Part 13: Perl Style

[Dan Richter]

LinuxChix Perl Course Part 13: Perl Style

1) Introduction
2) The Many Faces of Perl
3) The Special File Handle "ARGV"
4) Exercise
5) [Non-]Answer to Previous Exercise
6) Past Information
7) Credits
8) Licensing

             -----------------------------------

1) Introduction

An important concept in Perl is that "There Is More Than One Way To Do 
It" (TIMTOWTDY, pronounced "Tim Towtdy"). We have seen this to some 
degree already. A simple example is "tr///" and "y///", which mean 
exactly the same thing. As another example, "unless" is the same as "if 
not". Likewise, "s///" can usually do the job of "tr///".

This is one of the ways in which Perl is similar to human languages, 
which have many different words to express similar concepts (as a quick 
look through a thesaurus will demonstrate). Perl borrows other ideas 
from human languages as well. One simple example is the way "if" can be 
placed before or after the command to be conditionally executed. In 
addition, the implied use of "$_" is foreign to English speakers, but 
implied subjects are common in other languages such as Latin and Chinese.

Larry Wall, who invented Perl, is fascinated with human languages. He 
even studied them in graduate school - and for an interesting reason: 
"At the time, [my wife and I] were actually planning to be missionaries 
(more specifically, Bible translators), but we had to drop that idea for 
health reasons." But Wall doesn't regret the change of plans: he figures 
that Perl is actually more useful to the missionaries than he personally 
could have been.

Perl's similarity to a human language goes hand-in-hand with its ability 
to do many different types of jobs. As Jon Udell puts it, "[Larry] Wall 
[inventor of Perl] believes that people think about things in different 
ways, that natural languages accommodate many mindsets, and that 
programming languages should too."

We're now going to see a bit of Perl's human-language-like versatility.

             -----------------------------------

2) The Many Faces of Perl

As we have seen, Perl commands can be written as functions or statements.

   die("Error!") unless defined($foo);   # Look like functions.
   die "Error!"  unless defined $foo;    # Look like statements.

This changes the appearance only: the functionality is exactly the same.

More interestingly, the following code looks like it comes from a shell 
script, but it is actually valid Perl code:

   (-d $dir) || mkdir $dir;    # Create directory if it doesn't exist.
   $size=`wc -c $dir/*`;       # Get sizes of files.
   print <<EOF;
      Looks like
      everything's OK!
   EOF

Yes, Perl borrows "-d", "mkdir" back-ticks and "here-documents" (the 
"<<EOF" part) from your favourite shell.

Of course, the similarity is limited. Functions like "mkdir" are Perl 
built-ins; you cannot execute an arbitrary shell command directly from 
Perl. (That's why we had to use back-ticks to execute "wc".) In 
addition, you can't use "<", ">" and "|" to pipe I/O the way you would 
in a shell script (except when using "open", as we saw last week).

But I still think that it's impressive that a Perl program can be 
written like C or like a shell script.

             -----------------------------------

3) The Special File Handle "ARGV"

Okay, I admit that this section isn't too related to Perl style, but I 
had to put it somewhere!

"ARGV" is a special file handle which sequentially opens (for reading) 
all the files specified on the command-line (i.e., every command-line 
argument is interpreted as a file name and is opened). The files are 
read in the order in which they were specified on the command-line and 
as though the contents formed one big file (i.e., when you reach the end 
of a file, Perl automatically closes it and opens the next). The 
variable "$ARGV" always contains the name of the file that is currently 
being read by "<ARGV>".

In practice, you never see "<ARGV>". Instead, you see it written as 
"<>", because "ARGV" is the default file handle for reading if none is 
specified.

For example, consider the following code:

   while ( <> ) {    # while ( defined ( $_ = <ARGV> ) ) {
     print;          #  print $_;
   }

If you store this code in a file named "test.pl" and run:

   perl test.pl file1 file2 file3

the program will output the contents of "file1", then the contents of 
"file2", then the contents of "file3".

A dash ("-") given as a command-line argument refers to standard input. 
Also, if no command-line arguments are given at all, standard input is 
assumed.

             -----------------------------------

4) Exercise

The Unix program "cat" outputs data to standard out according to its 
command-line arguments, as follows:
1) If no command-line arguments are given, simply outputs standard input.
2) A command-line argument of "-" also means to output standard input.
3) Other command-line arguments refer to files, which are read and output.

The program is so called because it conCATenates data to standard output.

You will notice that this behaviour is very, very similar to the 
behaviour of "<ARGV>". (In fact, it's exactly the same, except that 
"cat" interprets arguemnts beginning with a dash as switches, whereas 
"<ARGV>" interprets them as files.) That's why "<ARGV>" is helpful: it's 
a shortcut to typical Unix behaviour.

Write a "polite cat" program that behaves like "cat", but makes harsh 
terms more polite. For example, you might replace "died" with "passed 
away". It's up to you exactly which terms you want to change. (You don't 
have to implement "cat"'s switches, of course.)

Try to use as few characters as possible without sacrificing good style.

             -----------------------------------

5) [Non-]Answer to Previous Exercise

There was no exercise last week.

             -----------------------------------

6) Past Information

Part 1: Getting Started
         http://linuxchix.org/pipermail/courses/2003-March/001147.html

Part 2: Scalar Data
         http://linuxchix.org/pipermail/courses/2003-March/001153.html

Part 3: User Input
         http://linuxchix.org/pipermail/courses/2003-April/001170.html

Part 4: Control Structures
         http://linuxchix.org/pipermail/courses/2003-April/001184.html

Part 4.5, a review with a little new information at the end:
         http://linuxchix.org/pipermail/courses/2003-July/001297.html

Part 5: The "tr///" Operator
         http://linuxchix.org/pipermail/courses/2003-July/001302.html

Part 6: The "m//" Operator
         http://linuxchix.org/pipermail/courses/2003-August/001305.html

Part 7: More About "m//"
         http://linuxchix.org/pipermail/courses/2003-August/001322.html

Part 8: The "s///" Operator
         http://linuxchix.org/pipermail/courses/2003-August/001330.html

Part 9: Simple File Access
         http://linuxchix.org/pipermail/courses/2003-September/001340.html

Part 10: Executing Commands with "open"
      http://linuxchix.org/pipermail/courses/2003-September/001344.html

Part 11: Perl Variables
      http://linuxchix.org/pipermail/courses/2003-October/001345.html

Part 12: Side Effects with Perl Variables
      http://linuxchix.org/pipermail/courses/2003-October/001347.html

             -----------------------------------

7) Credits

Works cited:
a) Jon Udell, "A Perl Hacker in the Land of Python"
    which you can view here:
    http://www.byte.com/documents/BYT20000201S0001/
    or if you don't feel like registering with BYTE.com:
    http://www.my-opensource.org/lists/myoss/2000-02/msg00090.html
b) Marjorie Richardson's interview of Larry Wall, found at:
    http://www.linuxjournal.com/article.php?sid=3394

Thanks to Jacinta Richardson for fact checking.

             -----------------------------------

8) Licensing

This course (i.e., all parts of it) is copyright 2003 by Alice Wood and 
Dan Richter, and is released under the same license as Perl itself 
(Artistic License or GPL, your choice). This is the license of choice to 
make it easy for other people to integrate your Perl code/documentation 
into their own projects. It is not generally used in projects unrelated 
to Perl.