abs-book.sgml

一本完整的描述Unix Shell 编程的工具书的所有范例

    </revhistory>


    <abstract>

      <para>This tutorial assumes no previous knowledge of
	scripting or programming, but progresses rapidly toward an
	intermediate/advanced level of instruction <emphasis>. . . all
	the while sneaking in little snippets of <trademark
	class=registered>UNIX</trademark> wisdom and lore</emphasis>. It
	serves as a textbook, a manual for self-study, and a reference and
	source of knowledge on shell scripting techniques. The exercises
	and heavily-commented examples invite active reader participation,
	under the premise that <userinput>the only way to really learn
	scripting is to write scripts</userinput>.</para>

      <para>This book is suitable for classroom use as a general
        introduction to programming concepts.</para>

      <para><ulink
        url="http://personal.riverusers.com/~thegrendel/abs-guide-3.7.tar.bz2">
        The latest update of this document</ulink>, as an archived, <link
	linkend="bzipref">bzip2-ed</link> <quote>tarball</quote>
	including both the SGML source and rendered HTML, may
	be downloaded from the author's home site. A <ulink
	url="http://www.tldp.org/LDP/abs/abs-guide.pdf">pdf
	version</ulink> is also available. See the <ulink
	url="http://personal.riverusers.com/~thegrendel/Change.log">change
	log</ulink> for a revision history.</para>

    </abstract>
  </bookinfo>

  <dedication>
    <para>For Anita, the source of all the magic</para>
  </dedication>



  <part label="Part 1" id="part1">
    <title>Introduction</title>

  <partintro>  

    <para>The shell is a command interpreter. More than just the
      insulating layer between the operating system kernel and the user,
      it's also a fairly powerful programming language.  A shell program,
      called a <firstterm>script</firstterm>, is an easy-to-use tool for
      building applications by <quote>gluing</quote> together system
      calls, tools, utilities, and compiled binaries.  Virtually the
      entire repertoire of UNIX commands, utilities, and tools is
      available for invocation by a shell script.  If that were
      not enough, internal shell commands, such as testing and loop
      constructs, give additional power and flexibility to scripts.
      Shell scripts lend themselves exceptionally well to administrative
      system tasks and other routine repetitive jobs not requiring the
      bells and whistles of a full-blown tightly structured programming
      language.</para>

  </partintro>  

  <chapter id="why-shell">
    <title>Why Shell Programming?</title>

    <epigraph>
      <attribution>Herbert Mayer</attribution>
      <para>No programming language is perfect. There is not even a single
        best language; there are only languages well suited or perhaps poorly
	suited for particular purposes.</para>
    </epigraph>
    
    
    <para>A working knowledge of shell scripting is essential to anyone
      wishing to become reasonably proficient at system administration,
      even if they do not anticipate ever having to actually write a
      script. Consider that as a Linux machine boots up, it executes the
      shell scripts in <filename class="directory">/etc/rc.d</filename>
      to restore the system configuration and set up services. A detailed
      understanding of these startup scripts is important for analyzing
      the behavior of a system, and possibly modifying it.</para>

    <para>Writing shell scripts is not hard to learn, since the scripts
      can be built in bite-sized sections and there is only a fairly
      small set of shell-specific operators and options
     
      <footnote><para>These are referred to as <link
        linkend="builtinref">builtins</link>, features internal to the
        shell.</para></footnote>

      to learn.  The syntax is simple and straightforward, similar to
      that of invoking and chaining together utilities at the command
      line, and there are only a few <quote>rules</quote> to learn.
      Most short scripts work right the first time, and debugging even
      the longer ones is straightforward.</para>

    <para>A shell script is a <quote>quick and dirty</quote> method of
      prototyping a complex application.  Getting even a limited subset
      of the functionality to work in a shell script is often a useful
      first stage in project development. This way, the structure of
      the application can be tested and played with, and the major
      pitfalls found before proceeding to the final coding in C, C++,
      Java, or Perl.</para>

    <para>Shell scripting hearkens back to the classic UNIX philosophy
      of breaking complex projects into simpler subtasks, of chaining
      together components and utilities. Many consider this a better,
      or at least more esthetically pleasing approach to problem solving
      than using one of the new generation of high powered all-in-one
      languages, such as Perl, which attempt to be all things to all
      people, but at the cost of forcing you to alter your thinking
      processes to fit the tool.</para>

    <para>When not to use shell scripts

      <itemizedlist>
	<listitem>
	  <para>Resource-intensive tasks, especially where speed is
	    a factor (sorting, hashing, etc.)</para>
	</listitem> <listitem>
	  <para>Procedures involving heavy-duty math operations,
	    especially floating point arithmetic, arbitrary precision
	    calculations, or complex numbers (use C++ or FORTRAN
	    instead)</para>
	</listitem> <listitem>
	  <para>Cross-platform portability required (use C or Java instead)</para>
	</listitem> <listitem>
	  <para>Complex applications, where structured programming is
	    a necessity (need type-checking of variables, function
	    prototypes, etc.)</para>
	</listitem> <listitem>
	  <para>Mission-critical applications upon which you are betting the
	    ranch, or the future of the company</para>
	</listitem> <listitem>
	  <para>Situations where security is important, where you need to
	    guarantee the integrity of your system and protect against
	    intrusion, cracking, and vandalism</para>
	</listitem> <listitem>
	  <para>Project consists of subcomponents with interlocking
	    dependencies</para>
	</listitem> <listitem>
	  <para>Extensive file operations required (Bash is limited to
	    serial file access, and that only in a particularly clumsy
	    and inefficient line-by-line fashion)</para>
	</listitem> <listitem>
	  <para>Need native support for multi-dimensional arrays</para>
	</listitem> <listitem>
	  <para>Need data structures, such as linked lists or trees</para>
	</listitem> <listitem>
	  <para>Need to generate or manipulate graphics or GUIs</para>
	</listitem> <listitem>
	  <para>Need direct access to system hardware</para>
	</listitem> <listitem>
	  <para>Need port or socket I/O</para>
	</listitem> <listitem>
	  <para>Need to use libraries or interface with legacy code</para>
	</listitem> <listitem>
	  <para>Proprietary, closed-source applications (shell scripts put the
	    source code right out in the open for all the world to see)</para>
	    
	</listitem>
      </itemizedlist></para>

    <para>If any of the above applies, consider a more powerful scripting
      language -- perhaps Perl, Tcl, Python, Ruby -- or possibly a
      high-level compiled language such as C, C++, or Java. Even then,
      prototyping the application as a shell script might still be a
      useful development step.</para>

    <para>We will be using <acronym>Bash</acronym>, an acronym for
      <quote>Bourne-Again shell</quote> and a pun on Stephen Bourne's
      now classic Bourne shell.  Bash has become a <foreignphrase>de
      facto</foreignphrase> standard for shell scripting on all flavors of
      UNIX. Most of the principles this book covers apply equally
      well to scripting with other shells, such as the Korn Shell,
      from which Bash derives some of its features,

       <footnote><para>Many of the features of <emphasis>ksh88</emphasis>,
	 and even a few from the updated <emphasis>ksh93</emphasis>
	 have been merged into Bash.</para></footnote>

      and the C Shell and its variants. (Note that C Shell programming
      is not recommended due to certain inherent problems, as pointed out
      in an October, 1993 <ulink
      url="http://www.etext.org/Quartz/computer/unix/csh.harmful.gz">Usenet
      post</ulink> by Tom Christiansen.)
      </para>

    <para>What follows is a tutorial on shell scripting. It relies
      heavily on examples to illustrate various features of the shell.
      The example scripts work -- they've been tested, insofar as was
      possible -- and some of them are even useful in real life. The
      reader can play with the actual working code of the examples
      in the source archive (<filename>scriptname.sh</filename> or
      <filename>scriptname.bash</filename>),

         <footnote><para>By convention, user-written shell scripts that are
	 Bourne shell compliant generally take a name with a
	 <filename>.sh</filename> extension.  System scripts, such as
	 those found in <filename class="directory">/etc/rc.d</filename>,
	 do not conform to this nomenclature.</para></footnote>

      give them execute permission (<userinput>chmod
      u+rx scriptname</userinput>), then run them
      to see what happens.  Should the source archive
      not be available, then cut-and-paste from the <ulink
      url="http://www.tldp.org/LDP/abs/abs-guide.html.tar.gz">HTML</ulink>,
      <ulink url="http://www.tldp.org/LDP/abs/abs-guide.pdf">pdf</ulink>,
      or <ulink
      url="http://www.ibiblio.org/pub/Linux/docs/linux-doc-project/abs-guide/abs-guide.txt.gz">text</ulink>
      rendered versions. Be aware that some of the scripts presented here
      introduce features before they are explained, and this may require
      the reader to temporarily skip ahead for enlightenment.</para>

    <para>Unless otherwise noted, <ulink
       url="mailto:[e-mail]">the author</ulink> of this
       book wrote the example scripts that follow.</para>

  </chapter> <!-- Why Shell Programming? -->


  <chapter id="sha-bang">
    <title>Starting Off With a Sha-Bang</title>

    <epigraph>
      <attribution>Larry Wall</attribution>
      <para>Shell programming is a 1950s juke box . . .</para> 
    </epigraph>

    <para>In the simplest case, a script is nothing more than a list of system
      commands stored in a file. At the very least, this saves the
      effort of retyping that particular sequence of commands each time
      it is invoked.</para>

    <example id="ex1">
      <title><command>cleanup</command>: A script to clean up the log
      files in /var/log </title> <programlisting>&ex1;</programlisting>
    </example>

    <para>There is nothing unusual here, only a set of commands that
      could just as easily be invoked one by one from the command line on
      the console or in an <firstterm>xterm</firstterm>. The advantages of
      placing the commands in a script go beyond not having to retype them
      time and again. The script becomes a <emphasis>tool</emphasis>,
      and can easily be modified or customized for a particular
      application.</para>

    <example id="ex1a">
      <title><command>cleanup</command>: An improved clean-up
      script</title> <programlisting>&ex1a;</programlisting>
    </example>

    <para>Now that's beginning to look like a real script. But we can
      go even farther . . .</para>

    <example id="ex2">
      <title><command>cleanup</command>: An enhanced
      and generalized version of above scripts.</title>
      <programlisting>&ex2;</programlisting>
    </example>

    <para>Since you may not wish to wipe out the entire system log,
      this version of the script keeps the last section of the message
      log intact. You will constantly discover ways of refining previously
      written scripts for increased effectiveness.</para>

    <para>The
      <firstterm><indexterm>
	  <primary>sha-bang</primary>
	</indexterm> sha-bang</firstterm>
      (<token>
	<indexterm>
	  <primary>#!</primary>
	</indexterm> #!</token>) at the head of a script
      tells your system that this file is a set of commands to be fed
      to the command interpreter indicated.  <anchor id="magnumref">The
      <token>#!</token> is actually a two-byte

        <footnote><para>Some flavors of UNIX (those based on 4.2BSD)
          take a four-byte magic number, requiring
          a blank after the <token>!</token> --
          <userinput>#! /bin/sh</userinput>.</para></footnote>

	<indexterm>
	  <primary>magic number</primary>
	</indexterm>
	<emphasis>magic number</emphasis>, a special marker that
	designates a file type, or in this case an executable shell
	script (type <userinput>man magic</userinput> for more
	details on this fascinating topic). Immediately following
	the <emphasis>sha-bang</emphasis> is a <firstterm>path
	name</firstterm>. This is the path to the program that interprets
	the commands in the script, whether it be a shell, a programming
	language, or a utility. This command interpreter then executes
	the commands in the script, starting at the top (line following
	the <emphasis>sha-bang</emphasis> line), ignoring comments.

	  <footnote>
	    <para>The <token>#!</token> line in a shell script
	      will be the first thing the command interpreter
	      (<command>sh</command> or <command>bash</command>)
	      sees. Since this line begins with a <token>#</token>,
	      it will be correctly interpreted as a comment when the
	      command interpreter finally executes the script. The
	      line has already served its purpose - calling the command
	      interpreter.</para>
	    <para>If, in fact, the script includes an
	      <emphasis>extra</emphasis> <token>#!</token> line, then
	      <command>bash</command> will interpret it as a comment.
	        <programlisting>#!/bin/bash

echo "Part 1 of script."
a=1

#!/bin/bash
# This does *not* launch a new script.

echo "Part 2 of script."
echo $a  # Value of $a stays at 1.</programlisting></para>
	   </footnote>

	</para>


    <para><programlisting>#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed -f
#!/usr/awk -f</programlisting></para>

    <para>Each of the above script header lines calls a different command
      interpreter, be it <filename>/bin/sh</filename>, the default shell
      (<command>bash</command> in a Linux system) or otherwise.

        <footnote>
	  <para>This allows some cute tricks.</para>
	  <para><programlisting>#!/bin/rm
# Self-deleting script.

# Nothing much seems to happen when you run this... except that the file disappears.

WHATEVER=65

echo "This line will never print (betcha!)."

exit $WHATEVER  # Doesn't matter. The script will not exit here.</programlisting></para>
      <para>Also, try starting a <filename>README</filename> file with a
        <userinput>#!/bin/more</userinput>, and making it executable.
        The result is a self-listing documentation file. (A <link
	linkend="heredocref">here document</link> using
	<link linkend="catref">cat</link> is possibly a better alternative
	-- see <xref linkend="ex71">).</para>
	</footnote>

      Using <userinput>#!/bin/sh</userinput>, the default Bourne shell
      in most commercial variants of UNIX, makes the script <link
      linkend="portabilityissues">portable</link> to non-Linux machines,
      though you sacrifice Bash-specific features.
      The script will, however, conform to the
      <acronym>POSIX</acronym>

	 <footnote>
	 <para><anchor id="posix2ref"><emphasis role="strong">P</emphasis>ortable
	 <emphasis role="strong">O</emphasis>perating
	 <emphasis role="strong">S</emphasis>ystem <emphasis
	 role="bold">I</emphasis>nterface, an attempt to
	 standardize UNI<emphasis role="strong">X</emphasis>-like
	 OSes. The POSIX specifications are listed on the <ulink
	 url="http://www.opengroup.org/onlinepubs/007904975/toc.htm">Open
	 Group site</ulink>.</para>
	 </footnote>

      <command>sh</command> standard.</para>

    <para>Note that the path given at the <quote>sha-bang</quote> must
      be correct, otherwise an error message -- usually <quote>Command
      not found</quote> -- will be the only result of running the