Online Documentation Server
Net technology
Web technology
Data bases
Other docs



Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.

Basic Linux Training

Lesson 13: perl and Shell Programming

Table of Contents


Larry Wall, who created perl, has described it this way:
perl is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks. The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author's opinion, anyway) some of the best features of C, sed, awk, and sh, so people familiar with those languages should have little difficulty with it. (Language historians will also note some vestiges of csh, Pascal, and even BASIC-PLUS.) Expression syntax corresponds quite closely to C expression syntax. Unlike most Unix utilities, Perl does not arbitrarily limit the size of your data--if you've got the memory, Perl can slurp in your whole file as a single string. Recursion is of unlimited depth. And the hash tables used by associative arrays grow as necessary to prevent degraded performance. Perl uses sophisticated pattern matching techniques to scan large amounts of data very quickly. Although optimized for scanning text, Perl can also deal with binary data, and can make dbm files look like associative arrays (where dbm is available). Setuid Perl scripts are safer than C programs through a dataflow tracing mechanism which prevents many stupid security holes. If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then perl may be for you. There are also translators to turn your sed and awk scripts into Perl scripts.

As you will notice quite soon, perl is extremely popular because it is easy to cobble a workable program together very quickly with a minimum of coding. It's similar to batch files and shell scripts in that it is interpreted rather than compiled, and has only a few requitrements:

  1. coding starts with the line to locate the perl interpreter
    	#! /usr/local/bin/perl

  2. comments begin with # and everything on the after the @ sign is ignored

  3. the perl script has the extension .pl

  4. you can make the script executable with
    	chmod +x
and that's about it! You can include tools like sed and awk to make your scripts extremely powerful and flexible. Then there's CGI (common graphic interface)...

More like than not, sooner or later you'll probably want to learn how to do it. The best book is Randall L Schwartz, Learning Perl, O'Reilly, ISBN 1-56592-04202, 274 pages, 1993. Learn the basics from that before you go on to Larry Wall, Tom Christiansen, Randall L Schwartz, Programming Perl, O'Reilly, ISBN 1-56592-149-6 or any of the other textbooks. It can get pretty dicey, whether you're a professional programmer or not, but this is much easier to learn than C for the 'casual' user.

The URLs below are the basics, but have links to virtually everything related to perl. In fact, there is more than enough material online that you could easily learn perl from the ground up without buying a textbook!

bash Shell Programming

Shell scripts are ASCII files that contain Unix and shell commands, and serve the same purpose as batch files in DOS - they execute a series of commands that you routinely use over and over, and the shell script is simply a convenience to save you time and typing errors. Instead of typing in the commands individually each time, you put them in a shell script file and run them sequentially by typing in the name of the script. Each script should have a unique name, just as batch files do, usually something that's easy to remember and related to what it's used for. There are several names you should not use (similar to DOS/Windows) - it's best to avoid conflicts with bash commands, programs and utilities.

You're already familiar with some of the basic Unix commands. Things like ls, cat, cd, mv.

Shell commands are those commands that are interpreted directly by the shell. Shell commands are commonly used for branching, looping, decision making, etc. They are similar to the commands in the C programming language.

For instance, if you wanted to rename a large number of files that have uppercase names, to lowercase names, a script could be written that would save you a lot of time and repetitious typing.

The bash shell scripts (as with batch files in DOS/Windows) let you do an amazing amount of work with just a few key strokes. Some of the more common things you can do are:

  • pass arguments to your script
  • set variables and reference them
  • use flow control commands like:
    • if then
    • if then else
    • while
    • for
  • prompt user for input and read user input

There are two ways you can execute your shell scripts:

  • Pass the file as an argument to the shell

    	sh script_file

    For example, suppose the file is named myscript. To run it you would type:

    	sh myscript

  • Make your script executable using the chmod u+x command.
    If the script is in a directory that is contained in your path variable, you can execute the script by just typing its name.

    	% chmod u+x myscript	
    	% myscript		
    The first command makes the shell script executable; the second one is the one you use to actually run the script.

    To insure that your script will be interpreted properly by the shell, you should insert the following line as the very first line, starting in the very first column in your script to identify where the perl interepreter is located:

    (#! is usually referred to as 'pound bang.')

    If you get the message "myscript: Command not found" all that means is that the myscript is not in your path. You can still run the script by typing the relative pathname for the script:

    (Generally, it's not a good idea to change the path in Unix/Linux; some programs and utilities will have the same name, others you probably don't want to run accidentally.)


Textbook, Running Linux:
  • Chapter 12: Programming Languages, p. 384-393

Textbook, A Practical Guide to Linux:

  • Chapter 11: Shell Programming

  • Chapter 12: The TC Shell

  • Chapter 13: The Z Shell and Advanced Shell Programming


Go to Basic Linux Index

Date last revised: 5 June 1998

Copyright © 1997, 1998 Henry White. All Rights Reserved.
Reproduction or redistribution without prior written consent is prohibited.
Address reprint requests and other inquiries to

With any suggestions or questions please feel free to contact us