JETZT ONLINE BESTELLEN
Add to Cart
Unix in a Nutshell

Fourth Edition Oktober 2005
ISBN 978-0-596-10029-2
906 Seiten
EUR29.00

Weitere Informationen zu diesem Buch

Inhaltsverzeichnis | Kolophon |


Inhaltsverzeichnis

	
Chapter 1: Introduction
Inhaltsvorschau
The Unix operating system originated at AT&T Bell Labs in the early 1970s. System V Release 4 (SVR4) came from USL (Unix System Laboratories) in the late 1980s. Unix source ownership is currently a matter of litigation in U.S. courts. Because Unix was able to run on different hardware from different vendors, developers were encouraged to modify Unix and distribute it as their own value-added version. Separate Unix traditions evolved as a result: USL's System V, the Berkeley Software Distribution (BSD, from the University of California, Berkeley), Xenix, etc.
SVR4, which was developed jointly by USL (then a division of AT&T) and Sun Microsystems, merged features from BSD and SVR3. This added about two dozen BSD commands (plus some new SVR4 commands) to the basic Unix command set. In addition, SVR4 provided a BSD Compatibility Package, a kind of "second string" command group. This package included some of the most fundamental BSD commands, and its purpose was to help users of BSD-derived systems make the transition to SVR4.
Today, the specification of what makes a system "Unix" is embodied primarily in the POSIX standard, an international standard based on System V and BSD. Commercial Unix systems, such as Solaris from Sun Microsystems, AIX from IBM, and HP-UX from Hewlett Packard, are standard-adhering direct descendants of the original Unix systems.
A number of other systems are "spiritual" descendents of Unix, even though they contain none of the original Unix source code. The most notable of these systems is GNU/Linux, which has seen a meteoric rise in popularity. However, a large number of systems derived from the 4.4-BSD-Lite distribution are also popular. All of these systems offer standards compliance and compatibility with SVR4 and earlier versions of BSD.
This edition of Unix in a Nutshell attempts to define the cross-section of features and commands that "make a Unix system Unix." To that end, it covers three of the most popular and representative systems now available.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Unix in the 21st Century
Inhaltsvorschau
Today, the specification of what makes a system "Unix" is embodied primarily in the POSIX standard, an international standard based on System V and BSD. Commercial Unix systems, such as Solaris from Sun Microsystems, AIX from IBM, and HP-UX from Hewlett Packard, are standard-adhering direct descendants of the original Unix systems.
A number of other systems are "spiritual" descendents of Unix, even though they contain none of the original Unix source code. The most notable of these systems is GNU/Linux, which has seen a meteoric rise in popularity. However, a large number of systems derived from the 4.4-BSD-Lite distribution are also popular. All of these systems offer standards compliance and compatibility with SVR4 and earlier versions of BSD.
This edition of Unix in a Nutshell attempts to define the cross-section of features and commands that "make a Unix system Unix." To that end, it covers three of the most popular and representative systems now available.
Solaris 10
Solaris 10 is a distributed computing environment from Sun Microsystems. Solaris includes the SunOS 5.10 operating system, plus additional features such as the Common Desktop Environment, GNOME, and Java tools. In addition, the kernel has received significant enhancement to support multiprocessor CPUs, multithreaded processes, kernel-level threads, and dynamic loading of device drivers and other kernel modules. Most of the user-level (and system administration) content comes from SVR4. As a result, Solaris 10 is based on SVR4 but contains additional BSD/SunOS features. To help in the transition from the old (largely BSD-based) SunOS, Solaris provides the BSD/SunOS Compatibility Package and the Binary Compatibility Package.
Sun has made binary versions of Solaris for the SPARC and Intel architectures available for "free," for noncommercial use. You pay only for the media, shipping, and handling, or you may download installation CD images. To find out more, see
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Obtaining Compilers
Inhaltsvorschau
If you wish to build programs from source code, you need a compiler. Almost all Unix applications are written in C or C++, with the majority still written in C. This section describes obtaining compilers for the three systems covered in this book.
Solaris 10 includes a Java compiler. Earlier versions of Solaris did not come with C or C++ compilers. You had to either buy compilers from Sun, from other third party vendors, or find a binary of some version of GCC for use in bootstrapping the latest version of GCC.
The final version of Solaris 10 now includes GCC (both C and C++ compilers) in /usr/sfw/bin. This is true for both the SPARC and Intel x86 versions. You thus have a choice: you may use the supplied GCC, or buy high-quality C and C++ compilers from Sun.
Besides GCC, a very large number of precompiled packages is available from http://www.sunfreeware.com/. You should see both the "Download/Install" and "FAQ" sections of that web site.
All the software from http://www.sunfreeware.com is in pkgadd format and is installable using that command. (See Chapter 6.) We recommend reading the details on the web site, which will always be up to date.
Note that many commands discussed in this book won't be on your system if all you've done is an end user install. If you can afford the disk space, do at least a developer install. This also installs many of the header files and libraries that you need in order to compile programs from source code.
For support issues and publicly released patches to Solaris, the web starting point is http://sunsolve.sun.com.
GNU/Linux systems usually install software development tools by default. If your system does not have compiler tools or
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Building Software
Inhaltsvorschau
Many of the programs listed in Chapter 2 are available in source code form from the Internet. For GNU/Linux and Mac OS X, you may be able to use a package manager to download and install the software (see Chapter 6). Similarly, for Solaris, you may be able to get a precompiled version of the program from http://www.sunfreeware.com/.
However, it's possible, particularly on a commercial Unix system, that you will want (or need) to download the source and build the program yourself if you don't have it, or if you wish to obtain the very latest version. This section outlines the conventional build process.
Most Internet software is written in C or C++. To compile it you will need a compiler. See the previous section for a discussion of where to get a compiler if you don't have one.
Today's programs usually use the GNU Project's Autoconf software suite for managing portability issues. Autoconf generates a shell script named configure, which tests various aspects of the target system. The end result of running configure is a Makefile custom-tuned to the particular system (see Chapter 16), and a header file describing the features available, or missing, from the system. As a result, the recipe for building software is usually quite simple, consisting of the following:
  1. Download the software. This can be done with a noninteractive program such as wget or curl (see their entries in Chapter 2), or interactively using anonymous FTP for programs distributed that way.
  2. Decompress and extract the software.
  3. Change directory into the program's distribution directory.
  4. Run configure.
  5. Run make.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
What's in the Quick Reference
Inhaltsvorschau
This guide presents the major features of Solaris, GNU/Linux, and Mac OS X. In addition, this guide presents chapters on Emacs, RCS, CVS, Subversion, GNU Make, and GDB, the GNU debugger. Although they are not part of commercial Unix systems, they are found on many Unix systems because they are useful add-ons.
But keep in mind: if your system doesn't include all the component packages, there will be commands in this book you won't find on your system.
The summary of Unix commands in Chapter 2 makes up a large part of this book. Only user/programmer commands are included; administrative commands are purposely ignored. Chapter 2 describes the following set:
  • Commands and options in Solaris, GNU/Linux, and Mac OS X. This includes many "essential" tools for which source and/or binaries are available via the Internet
  • Solaris-only tools
  • GNU/Linux-only tools
  • Mac OS X-only tools
  • Java-related tools
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Beginner's Guide
Inhaltsvorschau
If you're just beginning to work on a Unix system, the abundance of commands might prove daunting. To help orient you, the following lists present a small sampling of commands on various topics.
ftp
Interactive file transfer program.
login
Sign on to Unix.
mailx
Read or send mail.
slogin
Sign on to remote Unix using secure shell.
ssh
Connect to another system, securely.
cmp
Compare two files, byte by byte.
comm
Compare items in two sorted files.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Solaris: Standard Compliant Programs
Inhaltsvorschau
Where the behavior specified by the POSIX standard differs from the historical behavior provided by a command, Solaris provides a different version of the command in either /usr/xpg6/bin or in /usr/xpg4/bin. On Solaris systems, you should place these two directories into your search path before the standard /usr/bin directory. Some of these commands are not covered in this book, since they are either administrative commands or are obsolete. Also, today, it is unlikely that the commands in /usr/ucb will be useful; you probably should not have that directory in your search path.
ar
delta
file
kill
nm
tail
awk
df
find
link
nohup
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 2: Unix Commands
Inhaltsvorschau
This chapter presents the Unix commands of interest to users and programmers. Most of these commands appear in the "Commands" section of the online manual. With rare exception, this book purposely avoids system administration commands, because system administration is beyond its scope. The focus instead is on everyday commands, those used both interactively and for programming.
Summarizing three operating systems that are similar but not identical is a daunting task. In order to make a coherent presentation, the chapter is organized as follows:
Common Commands
This section lists commands that should be available on just about any Unix system. We have included here many commands that are downloadable from the Internet and that are standard with GNU/Linux, such as autoconf or wget, even though they may not come "out of the box" on commercial Unix systems. Wherever possible, we provide a URL from which the source to the command may be downloaded, so that you can build the program yourself if you want it. See the section "Obtaining Compilers" in Chapter 1 for what to do if you don't have a C compiler for your system.
Additionally, we have made an effort to be as concise as possible. For example, GNU-style long options are listed side-by-side with their standard single-letter counterparts. Similarly, several commands have associated with them additional more specialized commands that are needed only rarely. We simply list such commands as "related," without giving them separate entries. For such commands, you should then see your system's online manual pages or other documentation.
Solaris Commands
This section lists the important commands that are available only on Solaris.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Introduction
Inhaltsvorschau
This chapter presents the Unix commands of interest to users and programmers. Most of these commands appear in the "Commands" section of the online manual. With rare exception, this book purposely avoids system administration commands, because system administration is beyond its scope. The focus instead is on everyday commands, those used both interactively and for programming.
Summarizing three operating systems that are similar but not identical is a daunting task. In order to make a coherent presentation, the chapter is organized as follows:
Common Commands
This section lists commands that should be available on just about any Unix system. We have included here many commands that are downloadable from the Internet and that are standard with GNU/Linux, such as autoconf or wget, even though they may not come "out of the box" on commercial Unix systems. Wherever possible, we provide a URL from which the source to the command may be downloaded, so that you can build the program yourself if you want it. See the section "Obtaining Compilers" in Chapter 1 for what to do if you don't have a C compiler for your system.
Additionally, we have made an effort to be as concise as possible. For example, GNU-style long options are listed side-by-side with their standard single-letter counterparts. Similarly, several commands have associated with them additional more specialized commands that are needed only rarely. We simply list such commands as "related," without giving them separate entries. For such commands, you should then see your system's online manual pages or other documentation.
Solaris Commands
This section lists the important commands that are available only on Solaris.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Common Commands
Inhaltsvorschau
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Solaris Commands
Inhaltsvorschau
cde
Common Desktop Environment
The Common Desktop Environment (CDE) is one of the graphical user interfaces (GUI) on Solaris systems. Solaris users may choose between CDE and GNOME.
Documenting CDE would require its own book and is beyond the scope of this one. Instead, listed here are some of the more useful individual CDE commands, which are kept in /usr/dt/bin. (Commands for the Desktop.) In addition, a number of OpenWindows commands are still useful. See the listing under openwin .
Useful CDE Programs
The following CDE and Sun Desktop commands may be of interest. Check the manpages for more information.
answerbook2
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of GNU/Linux Commands
Inhaltsvorschau
GNU/Linux programs generally accept --help and --version options. In the interest of brevity, the individual command descriptions omit listing those options.
aspell

    aspell [options] [files]
aspell is intended to be a drop-in replacement for ispell, but with more functionality. It thus accepts the same options; see ispell for more information. See also spell in the earlier section "Alphabetical Summary of Common Commands."
URL: http://aspell.net/ and http://www.gnu.org/software/aspell/.
cdda2wav

    cdda2wav [options] [output.wav]
Convert Compact Disc Digital Audio (CDDA) to the WAV format. This process is often called "ripping" a CD-ROM, and is generally performed before using an encoder to convert the file to a compressed music format such as OGG or MP3. By default,
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Mac OS X Commands
Inhaltsvorschau
apply

    apply [options] command argument ...
Apply command to one or more of the following arguments in turn. command may contain a % followed by a digit from 1 to 9. Such text is replaced with the corresponding following unused argument.
Options
- N
Use arguments in groups of N. For example, -2 uses two arguments for each invocation of command. Occurrences of % N in command override this option.
-a char
Use char instead of % as the special character to represent arguments.
-d
Display the commands that would be executed, but don't actually execute them.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Java Commands
Inhaltsvorschau
appletviewer

    appletviewer [options] urls

                  
Connect to the specified urls and run any Java applets they specify in their own windows, outside the context of a web browser.
Options
-debug
Run the applet viewer from within the Java debugger, jdb.
-encoding name
Specify the input HTML file encoding.
-J java-option
Pass java-option on to the java program. Useful for changing the execution environment or memory usage. java-option should not contain spaces; use multiple -J options if necessary.
apt

    apt [options] [files ...] [@file ...]
Annotation processing tool. The
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 3: The Unix Shell: An Overview
Inhaltsvorschau
For novice users, this chapter presents basic concepts about the Unix shell. For advanced users, this chapter also summarizes the major similarities and differences between the Bash, Korn, and "Tenex" C shells . Details on the three shells are provided in Chapters 4 and 5.
The following topics are presented:
  • Introduction to the shell
  • Purpose of the shell
  • Shell flavors
  • Shell source code
  • Common features
  • Differing features
Today's microwave ovens, and many other household appliances (ovens, washing machines, dishwashers), let you use simple push-buttons to instruct them what to do. They provide a simple user interface to a possibly complicated internal system.
The shell is the user interface to Unix, and by the same token, several shells are available in Unix. Most systems provide more than one for you to choose from. Each shell has different features, but all of them affect how commands will be interpreted and provide tools to create your Unix environment.
The original shells were developed before the time of Graphical User Interfaces (GUIs), and at first glance, appear harder to use than GUI interfaces. The truth, though, is that they aren't harder to use, they are harder to learn. However, once you've mastered them, you'll find that you can accomplish an infinite variety of tasks that just cannot be managed with a GUI.
The shell is simply a program that allows the system to understand your commands. (That's why the shell is often called a command interpreter.) For many users, the shell works invisibly--"behind the scenes." Your only concern is that the system does what you tell it to do; you don't care about the inner workings. In our microwave analogy, this is comparable to pressing the START button. Most of us don't care whether the user interface communicates with an embedded microcomputer, or drives analog electronics, as long as the popcorn is ready in time for the movie, and doesn't burn.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Introduction to the Shell
Inhaltsvorschau
Today's microwave ovens, and many other household appliances (ovens, washing machines, dishwashers), let you use simple push-buttons to instruct them what to do. They provide a simple user interface to a possibly complicated internal system.
The shell is the user interface to Unix, and by the same token, several shells are available in Unix. Most systems provide more than one for you to choose from. Each shell has different features, but all of them affect how commands will be interpreted and provide tools to create your Unix environment.
The original shells were developed before the time of Graphical User Interfaces (GUIs), and at first glance, appear harder to use than GUI interfaces. The truth, though, is that they aren't harder to use, they are harder to learn. However, once you've mastered them, you'll find that you can accomplish an infinite variety of tasks that just cannot be managed with a GUI.
The shell is simply a program that allows the system to understand your commands. (That's why the shell is often called a command interpreter.) For many users, the shell works invisibly--"behind the scenes." Your only concern is that the system does what you tell it to do; you don't care about the inner workings. In our microwave analogy, this is comparable to pressing the START button. Most of us don't care whether the user interface communicates with an embedded microcomputer, or drives analog electronics, as long as the popcorn is ready in time for the movie, and doesn't burn.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Purpose of the Shell
Inhaltsvorschau
There are three uses for the shell:
  • Interactive use
  • Customization of your Unix session
  • Programming
When the shell is used interactively, the system waits for you to type a command at the Unix prompt. Your commands can include special symbols that let you abbreviate filenames or redirect input and output.
A Unix shell defines variables to control the behavior of your Unix session. Setting these variables tells the system, for example, which directory to use as your home directory, or the file in which you store your mail. Some variables are preset by the system; you can define others in startup files that are read when you log in. Startup files can also contain Unix commands or special shell commands. These are executed every time you log in. Many shells also support special variables and internal commands that let you tailor the behavior of the shell itself.
Unix shells provide a set of special (or built-in) commands that let you create programs called shell scripts . In fact, many built-in commands can be used interactively like Unix commands, and Unix commands are frequently used in shell scripts. Scripts are useful for executing a series of individual commands. This is similar to BATCH files in MS-DOS and Windows. Scripts can also execute commands repeatedly (in a loop) or conditionally (if-else), as in many high-level programming languages.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Shell Flavors
Inhaltsvorschau
Many different Unix shells are available. This quick reference describes the three most popular shells:
  • The GNU Project's Bash (Bourne-Again SHell), arguably the most popular shell in use today. It is a superset of the original Bourne shell , including command-line editing and many features first implemented in the Korn shell.
  • The Korn shell, a superset of the original Bourne shell that lets you edit the command line. There are two commonly available versions of the Korn shell, distinguished by the year they were released, and referred to in this book as ksh88 and ksh93 respectively.
  • The "Tenex" C shell, an enhanced version of the original BSD C shell, which uses C-like syntax and is more convenient for the interactive user than the original Bourne shell.
The original Bourne shell is available as /bin/sh on commercial Unix systems, and if invoked as sh, Bash will do its best to emulate the original Bourne shell's behavior. However, it is rare today to find the original Bourne shell being used interactively as a login shell; other shells that provide better interactive features and the Bourne shell's programming language, such as Bash and ksh, are more popular. However, when writing shell scripts, most people are careful to restrict themselves to just those features of the Bourne shell.
The /etc/passwd file determines which shell takes effect during your interactive Unix session. When you log in, the system checks your entry in /etc/passwd. The last field of each entry names a program to run as the default shell. For example:
If the program name is:
Your shell is the:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Shell Source Code URLs
Inhaltsvorschau
Here is a list of URLs for the source code for different shells.
Shell
Location
Bash
ftp://ftp.gnu.org/gnu/bash
Bash source code patches
ftp://ftp.gnu.org/gnu/bash/bash-3.0-patches
Ksh93
http://www.research.att.com/sw/download/
The Z Shell
http://www.zsh.org
The Public Domain Korn Shell
http://web.cs.mun.ca/~michael/pdksh/
Tcsh
http://www.tcsh.org
The Public Domain Korn shell is mostly compatible with ksh88, and is usually the version of ksh shipped with GNU/Linux systems. The Z shell (zsh) has many features of the Bourne shell, Bash, and the Korn shell, and a plethora of features unique to it.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Common Features
Inhaltsvorschau
The following table displays features that are common to the Bash, Korn, and C shells. Note that both the Korn shell and Bash are enhanced versions of the Bourne shell; therefore, they include all features of the Bourne shell, plus some others.
Symbol/command
Meaning/action
a Brace expansion is a compile-time feature in the Korn shell. Usually commercial versions don't have it, but if you compile from source code, you do get it by default.
>
Redirect output.
>>
Append to file.
<
Redirect input.
<<
"Here" document (redirect input).
|
Pipe output.
&
Run process in background.
;
Separate commands on same line.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Differing Features
Inhaltsvorschau
The following table displays features that are different among the three shells.
bash
ksh
tcsh
Meaning/action
$
$
%
Prompt.
>|
>|
>!
Force redirection.
>>!
Force append.
> file 2>&1
> file 2>&1
>& file
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 4: The Bash and Korn Shells
Inhaltsvorschau
The original Bourne shell distributed with V7 Unix in 1979 became the standard shell for writing shell scripts. The Bourne shell is still to be found in /bin/sh on many commercial Unix systems. The Bourne shell itself has not changed that much since its initial release, although it has seen modest enhancements over the years. The most notable new features were the CDPATH variable and a built-in test command with System III (circa 1980), command hashing and shell functions for System V Release 2 (circa 1984), and the addition of job control features for System V Release 4 (1989).
Because the Berkeley C shell (csh) offered features that were more pleasant for interactive use, such as command history and job control, for a long time the standard practice in the Unix world was to use the Bourne shell for programming and the C shell for daily use. David Korn at Bell Labs was the first developer to enhance the Bourne shell by adding csh-like features to it: history, job control, and additional programmability. Eventually, the Korn shell's feature set surpassed both the Bourne shell and the C shell, while remaining compatible with the Bourne shell for shell programming. Today, the POSIX standard defines the "standard shell" language and behavior based on the System V Bourne shell, with a selected subset of features from the Korn shell.
On most commercial Unix systems, including Solaris, /bin/ksh is ksh88 . On Mac OS X (10.4 and newer), however, it's a recent version of ksh93 from AT&T Research.
The Free Software Foundation, in keeping with its goal to produce a complete Unix work-alike system, developed a clone of the Bourne shell, written from scratch, named "Bash," the Bourne-Again SHell. Over time, Bash has become a POSIX-compliant version of the shell, with many additional features. A large part of these additional features overlap the features of the Korn shell, but Bash is not an exact Korn shell clone.
This chapter covers Bash , which is the primary shell for GNU/Linux and Mac OS X. Because
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Overview of Features
Inhaltsvorschau
The Bash and Korn shells provide the following features:
  • Input/output redirection
  • Wildcard characters (metacharacters) for filename abbreviation
  • Shell variables and options for customizing your environment
  • A built-in command set for writing shell programs
  • Shell functions, for modularizing tasks within a shell program
  • Job control
  • Command-line editing (using the command syntax of either vi or Emacs)
  • Access to previous commands (command history)
  • Integer arithmetic
  • Arrays and arithmetic expressions
  • Command-name abbreviation (aliasing)
ksh93 and Bash (but not ksh88) have the following capabilities:
  • Upwards compliance with POSIX
  • Internationalization facilities
  • An arithmetic for loop
  • More ways to substitute variables
ksh93 adds the following capabilities:
  • Floating-point arithmetic and built-in arithmetic functions
  • Structured variable names and indirect variable references
  • Associative arrays
  • More ways to match patterns
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Invoking the Shell
Inhaltsvorschau
The command interpreter for the Bash shell (bash) or the Korn shell (ksh) can be invoked as follows:

    bash  [options]  [arguments]

    ksh   [options]  [arguments]
ksh and Bash can execute commands from a terminal, from a file (when the first argument is an executable script), or from standard input (if no arguments remain or if -s is specified). Both shells automatically print prompts if standard input is a terminal, or if -i is given on the command line.
On many systems, /bin/sh is a link to Bash. When invoked as sh, Bash acts more like the traditional Bourne shell: login shells read /etc/profile and ~/.profile, and regular shells read $ENV, if it's set. Full details are available in the bash(1) manpage.

Section 4.2.1.1: Common options

-c str
Read commands from string str.
-D
Print all $"..." strings in the program. Not ksh88.
-i
Create an interactive shell (prompt for input).
-p
Start up as a privileged user. Bash: don't read $ENV or $BASH_ENV, don't import functions from the environment, and ignore the value of $SHELLOPTS. Korn shell: don't process
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Syntax
Inhaltsvorschau
This section describes the many symbols peculiar to the Bash and Korn shells . The topics are arranged as follows:
  • Special files
  • Filename metacharacters
  • Quoting
  • Command forms
  • Redirection forms
  • Coprocesses (Korn shell only)
Both shells read one or more start-up files. Some of the files are read only when a shell is a login shell.
The Korn shell reads these files:
  1. /etc/profile. Executed automatically at login, first.
  2. ~/.profile. Executed automatically at login, second.
  3. $ENV. Specifies the name of a file to read when a new Korn shell is created. (ksh88: all shells. ksh93: interactive shells only.) The value is variable (ksh93: and command and arithmetic) substituted in order to determine the actual file name. Login shells read $ENV after processing the files /etc/profile and $HOME/.profile.
Bash reads these files:
  1. /etc/profile. Executed automatically at login, first.
  2. The first file found from this list: ~/.bash_profile, ~/.bash_login, or ~/.profile. Executed automatically at login, second.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Functions
Inhaltsvorschau
A shell function is a grouping of commands within a shell script. Shell functions let you modularize your program by dividing it up into separate tasks. This way the code for each task need not be repeated every time you need to perform the task. The POSIX shell syntax for defining a function follows the Bourne shell:

               name () {

        function body's code come here

    }
Functions are invoked just as are regular shell built-in commands or external commands. The command line parameters $1, $2, and so on receive the function's arguments, temporarily hiding the global values of $1, etc. For example:

    # fatal --- print an error message and die:



    fatal () {

        echo "$0: fatal error:" "$@" >&2     # messages to standard error

        exit 1

    }

    ...

    if [ $# = 0 ]    # not enough arguments

    then

        fatal not enough arguments

    fi
A function may use the return command to return an exit value to the calling shell program. Be careful not to use exit from within a function unless you really wish to terminate the entire program.
Bash and the Korn shell allow you to define functions using an additional keyword, function, as follows:

    function fatal {

        echo "$0: fatal error:" "$@" >&2     # messages to standard error

        exit 1

    }
When working with the different shells and defining functions, there are semantic differences that should be kept in mind:
  • In Bash, all functions share traps with the "parent" shell (except the DEBUG trap, if function tracing has been turned on). With the errtrace option enabled (either set -E or set -o errtrace), functions also inherit the ERR trap. If function tracing has been enabled, functions inherit the RETURN trap. Functions may have local variables, and they may be recursive. The syntax used to define a function is irrelevant.
  • In ksh88
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Variables
Inhaltsvorschau
This section describes the following:
  • Variable substitution
  • Built-in shell variables
  • Other shell variables
  • Arrays
  • Discipline functions (ksh93 only)
  • Special prompt strings
ksh93 provides structured variables, such as pos.x and pos.y. To create either one, pos must already exist, and braces must be used to retrieve their values. Names beginning with .sh are reserved for use by ksh.
No spaces should be used in the following expressions. The colon (:) is optional; if it's included, var must be nonnull as well as set.
var = value ...
Set each variable var to a value.
${ var }
Use value of var; braces are optional if var is separated from the following text. They are required for array variables, and in ksh93 if a variable name contains periods.
${ var :- value }
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Arithmetic Expressions
Inhaltsvorschau
The let command performs arithmetic. ksh88 and Bash are restricted to integer arithmetic. ksh93 can do floating-point arithmetic as well. Both shells provide a way to substitute arithmetic values (for use as command arguments or in variables); base conversion is also possible:
$(( expr ))
Use the value of the enclosed arithmetic expression.
B # n
Interpret integer n in numeric base B. For example, 8#100 specifies the octal equivalent of decimal 64.
The shells use arithmetic operators from the C programming language, in decreasing order of precedence. ksh88 does not support the ++, --, unary +, ?:, comma, or ** operators. Early versions of ksh93 do not have **.
Operator
Description
a In ksh93, the ** operator is right-associative. In bash versions prior to 3.1, it is left-associative. It will be changed to right-associative starting with version 3.1.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command History
Inhaltsvorschau
Both shells let you display or modify previous commands. Commands in the history list can be modified using:
  • Line-edit mode
  • The fc and hist commands
Bash also supports a command history mechanism very similar to that of the C shell. Because the interactive line-editing features are considerably superior, and because Bash's command history is almost identical to that of the C shell, we have chosen not to cover those features here. See Chapter 5 and the Bash manpage for more information.
Line-edit mode emulates many features of the vi and emacs editors. The history list is treated like a file. When the editor is invoked, you type editing keystrokes to move to the command line you want to execute. You can also change the line before executing it. When you're ready to issue the command, press the ENTER key.
In ksh, line-edit mode can be started in several ways. For example, these are equivalent:

    $ VISUAL=vi

    $ EDITOR=vi

    $ set -o vi      

                  Overrides value of VISUAL or EDITOR

               
For Bash, you must use either set -o vi or set -o emacs; assignment to the VISUAL or EDITOR variables has no effect.
Note that vi starts in input mode; to type a vi command, press the Escape key first.

Section 4.7.1.1: Common editing keystrokes

vi
emacs
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Job Control
Inhaltsvorschau
Job control lets you place foreground jobs in the background, bring background jobs to the foreground, or suspend (temporarily stop) running jobs. All modern Unix systems, including Linux and BSD systems, support job control ; thus, the job control features are automatically enabled. Many job control commands take a jobID as an argument. This argument can be specified as follows:
% n
Job number n.
% s
Job whose command line starts with string s.
%? s
Job whose command line contains string s.
%%
Current job.
%+
Current job (same as above).
%-
Previous job.
Both shells provide the following job control commands. For more information on these commands, see the section "Built-in Commands (Bash and Korn Shells)" later in this chapter.
bg
Put a job in the background.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command Execution
Inhaltsvorschau
When you type a command to Bash or ksh93, they look in the following places until they find a match:
  1. Keywords such as if and for.
  2. Aliases. You can't define an alias whose name is a shell keyword, but you can define an alias that expands to a keyword, e.g., alias aslongas=while. (Bash, when not in POSIX mode, does allow you to define an alias for a shell keyword.)
  3. Special built-ins like break and continue. The list of POSIX special built-ins is . (dot), :, break, continue, eval, exec, exit, export, readonly, return, set, shift, times, trap, and unset. The Korn shell adds alias, login, typeset, and unalias, while Bash adds source.
  4. Functions. When not in POSIX mode, Bash finds functions before built-in commands.
  5. Nonspecial built-ins like cd and test.
  6. Scripts and executable programs, for which the shell searches in the directories listed in the PATH environment variable.
The distinction between "special" built-in commands and nonspecial ones comes from POSIX. This distinction, combined with the command command, makes it possible to write functions that override shell built-ins, such as cd. For example:

    cd () {                       Shell function; found before built-in cd

        command cd "$@"           Use real cd to change directory

        echo now in $PWD          Other stuff we want to do

    }
In ksh88, the search order is different, all built-ins are found before shell functions. Thus you have to do more work to override a built-in command with a function. You do so using a combination of functions and aliases:

    _cd () {                      Shell function; note leading underscore

        cd "$@"                   Use real cd to change directory

        echo now in $PWD          
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Restricted Shells
Inhaltsvorschau
A restricted shell is one that disallows certain actions, such as changing directory, setting PATH, or running commands whose names contain a / character.
The original V7 Bourne shell had an undocumented restricted mode. Later versions of the Bourne shell clarified the code and documented the facility. Today, Bash and the Korn shell both supply a restricted mode, but with differing sets of items that get restricted. (See the respective manual pages for the details.)
Shell scripts can still be run, since in that case the restricted shell calls the unrestricted version of the shell to run the script. This includes the /etc/profile, $HOME/.profile, and other start-up files.
Restricted shells are not used much in practice, as they are difficult to set up correctly.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Built-in Commands (Bash and Korn Shells)
Inhaltsvorschau
Examples to be entered as a command line are shown with the $ prompt. Otherwise, examples should be treated as code fragments that might be included in a shell script. For convenience, some of the reserved words used by multiline commands are also included.
!

    ! pipeline

                  
Not ksh88. Negate the sense of a pipeline. Returns an exit status of 0 if the pipeline exited nonzero, and an exit status of 1 if the pipeline exited zero. Typically used in if and while statements.
Example
This code prints a message if user
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 5: tcsh: An Extended C Shell
Inhaltsvorschau
This chapter describes tcsh, an enhanced version of the C shell. On many systems, tcsh is also the regular C shell (/bin/csh); in that case, the tcsh features described in this chapter work even when you run csh. The C shell was so named because many of its programming constructs and symbols resemble those of the C programming language. The following topics are presented:
  • Overview of features
  • Invoking the shell
  • Syntax
  • Variables
  • Expressions
  • Command history
  • Command-line manipulation
  • Job control
  • Built-in commands
For more information on tcsh, see Using csh & tcsh, which is listed in the Bibliography. The web site for tcsh is http://www.tcsh.org.
Features of tcsh include:
  • Input/output redirection
  • Wildcard characters (metacharacters) for filename abbreviation
  • Shell variables for customizing your environment
  • Integer arithmetic
  • Access to previous commands (command history)
  • Command-name abbreviation (aliasing)
  • A built-in command language for writing shell programs
  • Job control
  • Command-line editing and editor commands
  • Word completion (tab completion)
  • Spellchecking
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Overview of Features
Inhaltsvorschau
Features of tcsh include:
  • Input/output redirection
  • Wildcard characters (metacharacters) for filename abbreviation
  • Shell variables for customizing your environment
  • Integer arithmetic
  • Access to previous commands (command history)
  • Command-name abbreviation (aliasing)
  • A built-in command language for writing shell programs
  • Job control
  • Command-line editing and editor commands
  • Word completion (tab completion)
  • Spellchecking
  • Scheduled events, such as logout or terminal locking after a set idle period and delayed commands
  • Read-only variables
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Invoking the Shell
Inhaltsvorschau
The tcsh shell can be invoked as follows:
tcsh [ options ] [ arguments ]
tcsh executes commands from a terminal or a file. The options -n, -v, and -x are useful when debugging scripts.
-b
Allow the remaining command-line options to be interpreted as options to a specified command rather than as options to tcsh itself.
-c
Read and execute commands specified by the argument that follows and place any remaining arguments in the argv shell variable.
-d
Load directory stack from ~/.cshdirs even if not a login shell.
-e
Exit if a command produces errors.
-f
Fast startup; start without executing .tcshrc or .login.
-i
Invoke interactive shell (prompt for input) even if not on a terminal.
-l
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Syntax
Inhaltsvorschau
This section describes the syntax used by tcsh . The topics are arranged as follows:
  • Special files
  • Filename metacharacters
  • Quoting
  • Command forms
  • Redirection forms
Filename
Description
/etc/csh.cshrc
Read by any shell before reading per-user initialization files.
~/.tcshrc or ~/.cshrc
Executed at each instance of shell startup. If no ~/.tcshrc is found, tcsh tries ~/.cshrc.
/etc/csh.login
Read by login shell before reading per-user initialization files.
~/.login
Executed by login shell after
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Variables
Inhaltsvorschau
This subsection describes the following:
  • Variable substitution
  • Variable modifiers
  • Predefined shell variables
  • Formatting in the prompt variable
  • Sample .tcshrc file
  • Environment variables
In the following substitutions, braces ({ }) are optional, except when needed to separate a variable name from following characters that would otherwise be considered part of the name.
Variable
Description
${ var }
The value of variable var.
${ var [ i ]}
Select word or words in position i of var. i can be a single number, a range m-n, a range -n (missing m implies 1), a range m- (missing n implies all remaining words), or * (select all words). i also can be a variable that expands to one of these values.
${# var
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Expressions
Inhaltsvorschau
Expressions are used in @ (the C shell math operator), if, and while statements to perform arithmetic , string comparisons, file testing, and so on. exit and set also specify expressions , as can the tcsh built-in command filetest. Expressions are formed by combining variables and constants with operators that resemble those in the C programming language. Operator precedence is the same as in C. It is easiest to just remember the following precedence rules:
  • * / %
  • + -
  • Group all other expressions inside ()s; parentheses are required if the expression contains <, >, &, or |
Operators can be one of the following types.

Section 5.5.1.1: Assignment operators

Operator
Description
=
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command History
Inhaltsvorschau
Previously executed commands are stored in a history list. You can access this list to verify commands, repeat them, or execute modified versions of them. The history built-in command displays the history list; the predefined variables histchars, history, and savehist also affect the history mechanism. There are a number of ways to use the history list:
  • Rerun a previous command
  • Edit a previous command
  • Make command substitutions
  • Make argument substitutions (replace specific words in a command)
  • Extract or replace parts of a command or word
The easiest way to take advantage of the command history is to use the arrow keys to move around in the history, select the command you want, and then rerun it or use the editing features described in the section "Command-Line Editing," later in this chapter, to modify the command. The arrow keys are:
Key
Description
Up arrow ()
Previous command.
Down arrow ()
Next command.
Left arrow ()
Move left in command line.
Right arrow ()
Move right in command line.
The next sections describe some tools for editing and rerunning commands. With the C shell, which does not have the command-line editing features of
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Manipulation
Inhaltsvorschau
tcsh provides functionality for manipulating the command line, including word or command completion and the ability to edit a command line.
The shell automatically completes words and commands when you press the Tab key, and notifies you when a completion is finished by appending a space to complete filenames or commands and a / to complete directories.
In addition, tcsh recognizes ~ notation for home directories; it assumes that words at the beginning of a line and following |, &, ;, ||, or && are commands, and modifies the search path appropriately. Completion can be done midword; only the letters to the left of the cursor are checked for completion.
  • autolist
  • fignore
  • filec
  • listmax
  • listmaxrows
  • complete-word-back
  • complete-word-forward
  • expand-glob
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Job Control
Inhaltsvorschau
Job control lets you place foreground jobs in the background, bring background jobs to the foreground, or suspend (temporarily stop) running jobs. The shell provides the following commands for job control . For more information on these commands, see the following section, "Built-in Commands."
bg
Put a job in the background.
fg
Put a job in the foreground.
jobs
List active jobs.
kill
Terminate a job.
notify
Notify when a background job finishes.
stop
Suspend a background job.
CTRL-Z
Suspend the foreground job.
Many job-control commands take a jobID as an argument. This argument can be specified as follows:
% n
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Built-in Commands
Inhaltsvorschau
@

        @ variable = expression

        @ variable[n] = expression

        @
Assign the value of the arithmetic expression to variable, or to the nth element of variable if the index n is specified. With no variable or expression specified, print the values of all shell variables (same as set). Expression operators as well as examples are listed under the section "Expressions," earlier in this chapter. Two special forms are also valid:
@ variable ++
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 6: Package Management
Inhaltsvorschau
Package management systems automate the installation, removal and upgrade of software. Different systems do things in similar but not identical ways. GNU/Linux systems have the most highly developed package management systems. This chapter describes the facilities available for Linux, Solaris, and Mac OS X. It presents the following topics:
  • Linux package management
  • The Red Hat package manager
  • Yum: Yellowdog Updater Modified
  • up2date: Red Hat update agent
  • The Debian package manager
  • Mac OS X package management
  • Solaris package management
This chapter describes the two major Linux packaging systems: the Red Hat Package Manager (RPM) and the Debian GNU/Linux Package Manager. It also describes the major frontend applications designed to simplify and automate package management: yum and up2date for RPM-based systems, aptitude and synaptic for Debian-based systems, and apt, which is a Debian package management tool that is now also available for RPM-based systems.
When you install applications on your Linux system, most often you'll find a binary or a source package containing the application you want, instead of (or in addition to) a .tar.gz file. A package is a file containing the files necessary to install an application. However, while the package contains the files you need for installation, the application might require the presence of other files or packages that are not included, such as particular libraries (and even specific versions of the libraries), to actually be able to run. Such requirements are known as dependencies .
Package management systems offer many benefits. As a user, you may want to query the package database to find out what packages are installed on the system and their versions. As a system administrator, you need tools to install and manage the packages on your system. And if you are a developer, you need to know how to build a package for distribution.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Linux Package Management
Inhaltsvorschau
This chapter describes the two major Linux packaging systems: the Red Hat Package Manager (RPM) and the Debian GNU/Linux Package Manager. It also describes the major frontend applications designed to simplify and automate package management: yum and up2date for RPM-based systems, aptitude and synaptic for Debian-based systems, and apt, which is a Debian package management tool that is now also available for RPM-based systems.
When you install applications on your Linux system, most often you'll find a binary or a source package containing the application you want, instead of (or in addition to) a .tar.gz file. A package is a file containing the files necessary to install an application. However, while the package contains the files you need for installation, the application might require the presence of other files or packages that are not included, such as particular libraries (and even specific versions of the libraries), to actually be able to run. Such requirements are known as dependencies .
Package management systems offer many benefits. As a user, you may want to query the package database to find out what packages are installed on the system and their versions. As a system administrator, you need tools to install and manage the packages on your system. And if you are a developer, you need to know how to build a package for distribution.
Among other things, package managers do the following:
  • Provide tools for installing, updating, removing, and managing the software on your system.
  • Allow you to install new or upgraded software directly across a network.
  • Tell you what software package a particular file belongs to or what files a package contains.
  • Maintain a database of packages on the system and their status, so that you can determine what packages or versions are installed on your system.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The Red Hat Package Manager
Inhaltsvorschau
The Red Hat Package Manager (RPM) is a freely available packaging system for software distribution and installation. In addition to the Red Hat Enterprise Linux and Fedora Core distributions, both SuSE and Mandrake are among the Linux distributions that use RPM.
Using RPM is straightforward. A single command, rpm, has options to perform all package management functions except building packages. For example, to find out if the Emacs editor is installed on your system, you could say:

$ rpm -q emacs

emacs-21.3-17
This command prints the full package name, confirming its presence.
You use the rpmbuild command to build both binary and source packages.
This section provides an overview of some of the parts of an RPM package. Much of the information is of primary use to developers, but because some of the terms are referenced in the RPM command descriptions, they are explained briefly here.
An RPM package has three primary components. The header contains all the information about the package, such as its name and version, a description, a list of included files, the copyright terms, and where the source file can be found. The signature contains information used to verify the integrity and authenticity of the package. The archive contains the actual files that make up the package.
When a package is being built, one of the requirements for the developers is to create a spec file. If you download the source RPM for a package, you can look at the spec file; it has a filename of package .spec (e.g., yum.spec for the yum spec file). The spec file contains all the information required for building a package, including a description of the software, instructions telling the rpmbuild command how to build the package, and a list of the files included and where they get installed. Some other features of spec files include the following:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Yum: Yellowdog Updater Modified
Inhaltsvorschau
Yum is a system for managing RPM packages, including installing, updating, removing, and maintaining packages; it automatically handles dependencies between packages. Yum is derived from yup, an updating system written for Yellow Dog Linux, an RPM-based Macintosh distribution. Yum downloads the information in the package headers to a directory on your system, which it then uses to make decisions about what it needs to do. Yum obtains both the headers and the RPMs themselves from a collection of packages on a server, known as a repository.
A repository consists of a set of RPM packages and the package headers on a server that can be accessed via FTP or HTTP, from an NFS server, or from a local filesystem. A single server can contain multiple repositories, repositories are often mirrored on many servers, and you can configure yum to use multiple repositories. When they are downloaded to your system, the header and package files are maintained in /var/cache/yum.
The configuration file, /etc/yum.conf, is where you customize yum. It consists of two section types. The first section, [main], sets configuration defaults for yum operation. This section is followed by [ server ] sections, where each server is named according to the repository it specifies. For example, for Fedora Core, you might have [base] for the base Fedora Core repository and [development] for the development repository.
The server sections can also be stored, one to a file, in /etc/yum.repos.d. yum comes with a default yum.conf file, which you can use as-is or as a starting point from which to add additional repositories.
The yum command is an automated system for updating rpm-based packages, particularly on Fedora Core and Red Hat Enterprise Linux. Yum can automatically install, upgrade, and remove packages. In addition to individual packages or a list of packages, yum can operate on an entire group of packages at a time.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
up2date: Red Hat Update Agent
Inhaltsvorschau
The Red Hat Update Agent, up2date, installs and updates packages on RPM-based systems, primarily on Red Hat and Fedora Core Linux systems. Originally, up2date was intended for use with Red Hat Enterprise Linux and the Red Hat Network, but it has since been updated to work with yum and apt repositories as well. up2date operates on groupings of packages known as channels , based on the system architecture and Fedora Core or Red Hat Enterprise release. For example, a channel might be fedora-core-3, containing packages for that distribution; this type of channel is a base channel. Child channels are associated with a base channel and contain extra packages, such as for an application or a set of applications. Entries for the channels are found in /etc/sysconfig/rhn/sources. This file contains an entry for each channel that associates the repository type (e.g., up2date, yum, or apt) with a channel name and a URL in the case of a yum repository. For an apt repository, the URL is separated by spaces into parts: service:server, path, and repository name. You can also include entries for a local directory of packages, known as a dir repository.
up2date has both a command-line and a graphical interface; it is primarily the command-line interface that we describe in this section. If you are running GNOME or KDE and have the rhn-applet installed, clicking on the icon in the panel brings up the graphical up2date interface. The rhn-applet is the Red Hat Network Notification Tool, which runs in your desktop panel and notifies you when package updates are available. The panel icon is red with a blinking exclamation point if updates are available, and blue with a check mark if your system is up-to-date.
The format of the up2date command is:

up2date [options] [packages]
There are two additional commands:

up2date-nox [options] [packages]

up2date-config
Running up2date-nox
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The Debian Package Manager
Inhaltsvorschau
Debian GNU/Linux provides several package management tools, primarily intended to facilitate the building, installation, and management of binary packages. In addition to Debian GNU/Linux, the tools described here also work on other Debian-based systems such as Xandros, Knoppix, Ubuntu, and numerous others.
Debian package names generally end in .deb. The Debian package management tools described here include apt, aptitude, dpkg, dpkg-deb, dselect, and synaptic.
Each of these tools is described in detail in the section "Debian Package Manager Command Summary," later in this chapter.
Some important files used by the Debian package management tools are described briefly here:
control
Comes with each package. Documents dependencies; contains the name and version of the package, a description, maintainer, installed size, the package priority, etc.
conffiles
Comes with each package. Contains a list of the configuration files associated with the package.
preinst, postinst, prerm, postrm
Scripts that developers can include in a package to be run before installation, after installation, before removal, or after removal of the package.
/var/lib/dpkg/available
Contains information about packages available on the system.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mac OS X Package Management
Inhaltsvorschau
There are two freely available package management systems for Mac OS X.
The Fink project 's goal is to port important Open Source and Free Software to Darwin and Mac OS X. To that end, the project provides the Fink package management system, which makes it easy to install, upgrade, and uninstall Open Source software.
Fink is based on the Debian tools dpkg, dselect, and apt-get (described earlier in this chapter). It uses these tools to manage downloading, building, and installation of available packages. The current default location for installation is the /sw directory; this name does not conflict with any of the other standard Unix or Mac OS X installation directories, which keeps package management simple.
The Fink project is based at http://fink.sourceforge.net. From there you can download the fink command-line program and other tools and start downloading the packages that are available.
Fink Commander provides an Aqua-based GUI interface to Fink. The web starting point is http://finkcommander.sourceforge.net. A binary version of Fink Commander is included when you download Fink, so you don't have to build Fink Commander yourself.
For more information, including screenshots of Fink Commander, see the two web sites just cited.
The GNU Mac OS X Public Archive (OSXGNU) at http://www.osxgnu.org provides an alternative to Fink. It provides a package management system that extends the rudimentary facilities already available in Mac OS X (i.e., the standard Mac OS X installer facilities).
The advantage to the OSXGNU project is that you don't have to use a terminal to install packages; you just launch them. The OSXGNU project provides the OS X Package Manager , which is an Aqua-based GUI interface to the Mac OS X package management system. It lets you manage all the packages installed on your system, not just those downloaded from the OSXGNU site.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Solaris Package Management
Inhaltsvorschau
Solaris uses an enhanced version of the System V Release 4 package management system. These tools are used for installation of Sun's software and for software available from http://www.sunfreeware.com. The tools are different from those of GNU/Linux, since they do not manage automatic updating of installed packages. (pkgadd can, however, download and install packages provided with http:// URLs.)
If you need to create Solaris packages, you should read Sun's Application Packaging Developer's Guide. The Solaris 9 version of this document is currently available at http://docs.sun.com/app/docs/doc/806-7008/.
Adding and removing packages are straightforward operations: use the pkgadd and pkgrm commands. The pkginfo command provides information about installed packages. The pkgadm command provides rudimentary control over installed packages.
Creating packages is more involved, requiring the use of pkgproto to build a prototype(4) file and then pkgmk to actually create the package.
The installf and removef commands are useful when writing scripts to be run by pkgadd and pkgrm.
installf

/usr/sbin/installf [options] pkginst pathname                   [ftype [major minor] [mode owner group]]

/usr/sbin/installf [options] pkginst -

/usr/sbin/installf -f [options] pkginst

                     
installf adds a file to the system installation database that isn't listed in the pkgmap file. It's used for files created dynamically (such as device files in /dev) during package installation. All invocations supply the package name and instance,
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 7: Pattern Matching
Inhaltsvorschau
A number of Unix text-processing utilities let you search for, and in some cases change, text patterns rather than fixed strings. These utilities include the editing programs ed, ex, vi, and sed, the awk programming language, and the commands grep and egrep. Text patterns (called regular expressions in the computer science literature) contain normal characters mixed with special characters (called metacharacters ).
This chapter presents the following topics:
  • Filenames versus patterns
  • Description of metacharacters
  • List of metacharacters available to each program
  • Examples
For more information on regular expressions, see Mastering Regular Expressions, listed in the Bibliography.
Metacharacters used in pattern matching are different from metacharacters used for filename expansion (see Chapter 4 and Chapter 5). However, several metacharacters have meaning for both regular expressions and for filename expansion. This can lead to a problem: the shell sees the command line first, and can potentially interpret an unquoted regular expression metacharacter as a filename expansion. For example, the command:

$ grep [A-Z]* chap[12]

            
could be transformed by the shell into:

$ grep Array.c Bug.c Comp.c chap1 chap2

            
and grep would then try to find the pattern Array.c in files Bug.c, Comp.c, chap1, and chap2. To bypass the shell and pass the special characters to grep, use quotes as follows:

$ grep "[A-Z]*" chap[12]

            
Double quotes suffice in most cases, but single quotes are the safest bet, since the shell does absolutely no expansions on single-quoted text.
Note also that in pattern matching, ? matches zero or one instance of a regular expression; in filename expansion,
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Filenames Versus Patterns
Inhaltsvorschau
Metacharacters used in pattern matching are different from metacharacters used for filename expansion (see Chapter 4 and Chapter 5). However, several metacharacters have meaning for both regular expressions and for filename expansion. This can lead to a problem: the shell sees the command line first, and can potentially interpret an unquoted regular expression metacharacter as a filename expansion. For example, the command:

$ grep [A-Z]* chap[12]

            
could be transformed by the shell into:

$ grep Array.c Bug.c Comp.c chap1 chap2

            
and grep would then try to find the pattern Array.c in files Bug.c, Comp.c, chap1, and chap2. To bypass the shell and pass the special characters to grep, use quotes as follows:

$ grep "[A-Z]*" chap[12]

            
Double quotes suffice in most cases, but single quotes are the safest bet, since the shell does absolutely no expansions on single-quoted text.
Note also that in pattern matching, ? matches zero or one instance of a regular expression; in filename expansion, ? matches a single character.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Metacharacters
Inhaltsvorschau
Different metacharacters have different meanings, depending upon where they are used. In particular, regular expressions used for searching through text (matching) have one set of metacharacters, while the metacharacters used when processing replacement text (such as in a text editor) have a different set. These sets also vary somewhat per program. This section covers the metacharacters used for searching and replacing, with descriptions of the variants in the different utilities.
The characters in the following table have special meaning only in search patterns .
Character
Pattern
.
Match any single character except newline. Can match newline in awk.
*
Match any number (or none) of the single character that immediately precedes it. The preceding character can also be a regular expression. For example, since . (dot) means any character, .* means "match any number of any character."
^
Match the following regular expression at the beginning of the line or string.
$
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Metacharacters, Listed by Unix Program
Inhaltsvorschau
Some metacharacters are valid for one program but not for another. Those that are available are marked by a bullet (·) in Table 7-1. (This table is correct for most commercial Unix systems, including Solaris.) Items marked with a "P" are specified by POSIX; double-check your system's version. (On Solaris, the versions in /usr/xpg4/bin and /usr/xpg6/bin accept these items.) Full descriptions were provided in the previous section.
Table 7-1: Unix metacharacters
Symbol
ed
ex
vi
sed
awk
grep
egrep
Action
Stored subpatterns can be "replayed" during matching. See Table 7-2.
.
·
·
·
·
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Examples of Searching
Inhaltsvorschau
When used with grep or egrep, regular expressions should be surrounded by quotes. (If the pattern contains a $, you must use single quotes; e.g., ' pattern '.) When used with ed, ex, sed, and awk, regular expressions are usually surrounded by /, although (except for awk) any delimiter works. The following tables show some example patterns.
Pattern
What does it match?
bag
The string bag.
^bag
bag at the beginning of the line.
bag$
bag at the end of the line.
^bag$
bag as the only word on the line.
[Bb]ag
Bag or bag.
b[aeiou]g
Second letter is a vowel.
b[^aeiou]g
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 8: The Emacs Editor
Inhaltsvorschau
Although most commercial operating systems do not come with Emacs , it is available for all versions of Unix, including Mac OS X, and MS-Windows. (GNU/Linux systems usually do supply it.) On all these systems, there are often multiple versions: one for character terminals, another for X11, and possibly yet another for the native windowing system. This text editor is a popular alternative to vi. This chapter documents GNU Emacs (Version 21.3), which is available from the Free Software Foundation (http://www.gnu.org/software/emacs).
This chapter presents the following topics:
  • Conceptual overview
  • Command-line syntax
  • Summary of emacs commands by group
  • Summary of emacs commands by key
  • Summary of emacs commands by name
For more information about emacs, see Learning GNU Emacs, listed in the Bibliography.
This section describes some Emacs terminology that may be unfamiliar if you haven't used Emacs before.
One of the features that makes Emacs popular is its editing modes . The modes set up an environment designed for the type of editing you are doing, with features like having appropriate key bindings available, and automatically indenting according to standard conventions for a particular type of document. There are two types of modes, major and minor. The major modes include modes for various programming languages like C or Java, for text processing (e.g., SGML or even straight text), and many more. One particularly useful major mode is Dired (Directory Editor), which has commands that let you manage directories. Minor modes set or unset features that are independent of the major mode, such as auto-fill (which controls line wrapping), insert versus overwrite, and auto-save. For a full discussion of modes, see
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
This section describes some Emacs terminology that may be unfamiliar if you haven't used Emacs before.
One of the features that makes Emacs popular is its editing modes . The modes set up an environment designed for the type of editing you are doing, with features like having appropriate key bindings available, and automatically indenting according to standard conventions for a particular type of document. There are two types of modes, major and minor. The major modes include modes for various programming languages like C or Java, for text processing (e.g., SGML or even straight text), and many more. One particularly useful major mode is Dired (Directory Editor), which has commands that let you manage directories. Minor modes set or unset features that are independent of the major mode, such as auto-fill (which controls line wrapping), insert versus overwrite, and auto-save. For a full discussion of modes, see Learning GNU Emacs or the Emacs Info documentation system (C-h i).
When you open a file in Emacs, the file is put into a buffer so you can edit it. If you open another file, that file goes into another buffer. The view of the buffer contents that you have at any point in time is called a window. For a small file, the window might show the entire file; for a large file, it shows only a portion of a file. Emacs allows multiple windows to be open at the same time, to display the contents of different buffers or different portions of a single buffer.
When you are editing in Emacs, the position of the cursor is known as point
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
To start an Emacs editing session, type:

emacs [file]
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary of Commands by Group
Inhaltsvorschau
Reminder: C- indicates the Control key; M- indicates the Meta key.
Keystrokes
Command name
Description
C-x C-f
find-file
Find file and read it.
C-x C-v
find-alternate-file
Read another file; replace the one read with C-x C-f.
C-x i
insert-file
Insert file at cursor position.
C-x C-s
save-buffer
Save file (may hang terminal; use C-q to restart).
C-x C-w
write-file
Write buffer contents to file.
C-x C-c
save-buffers-kill-emacs
Exit emacs.
C-z
suspend-emacs
Suspend emacs (use exit
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary of Commands by Key
Inhaltsvorschau
Emacs commands are presented below in two alphabetical lists. Reminder: C- indicates the Control key; M- indicates the Meta key.
Keystrokes
Command name
Description
C-@
set-mark-command
Mark the beginning (or end) of a region.
C-Space
(same as previous)
C-]
(none)
Exit recursive edit and exit query-replace.
C-a
beginning-of-line
Move to beginning of line.
C-b
backward-char
Move backward one character (left).
C-c C-c
comint-interrupt-subjob
Terminate the current job.
C-c C-d
comint-send-eof
End-of-file character.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary of Commands by Name
Inhaltsvorschau
The emacs commands below are presented alphabetically by command name. Use M-x to access the command name. Reminder: C- indicates the Control key; M- indicates the Meta key.
Command name
Keystrokes
Description
macroname
(none)
Execute a keyboard macro you've saved.
abbrev-mode
(none)
Enter (or exit) word abbreviation mode.
advertised-undo
C-_
Undo last edit (can be done repeatedly).
apropos
(none)
What functions and variables involve this concept?
back-to-indentation
M-m
Move cursor to first nonblank character on line.
backward-char
C-b
Move backward one character (left).
backward-delete-char
Del
Delete previous character.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 9: The vi, ex, and vim Editors
Inhaltsvorschau
The vi and ex editors are the "standard" editors on Unix systems. You can count on there being some version of them, no matter what Unix flavor you are using. The two editors are in fact the same program; based on how the editor was invoked, it enters full-screen mode or line mode. vim is a popular extended version of vi.
This chapter presents the following topics:
  • Conceptual overview
  • Command-line syntax
  • Review of vi operations
  • Alphabetical list of keys in command mode
  • vi commands
  • vi configuration
  • ex basics
  • Alphabetical summary of ex commands
vi is pronounced "vee eye."
Besides the original Unix vi, there are a number of freely available vi clones (including vim). Both the original vi and the clones are covered in Learning the vi Editor, listed in the Bibliography. The Internet starting point for vim is http://www.vim.org.
vi is the classic screen-editing program for Unix. A number of enhanced versions exist, including nvi, vim, vile, and elvis. On GNU/Linux systems, the vi command is usually one of these programs (either a copy or a link). The Emacs editor, covered in Chapter 8, has several vi modes that allow you to use many of the same commands covered in this chapter.
The vi editor operates in two modes, command mode and insert mode. The dual mode makes vi an attractive editor for users who separate text entry from editing. For users who edit as they type, the modeless editing of emacs can be more comfortable. However, vim supports both ways of editing, through the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
vi is the classic screen-editing program for Unix. A number of enhanced versions exist, including nvi, vim, vile, and elvis. On GNU/Linux systems, the vi command is usually one of these programs (either a copy or a link). The Emacs editor, covered in Chapter 8, has several vi modes that allow you to use many of the same commands covered in this chapter.
The vi editor operates in two modes, command mode and insert mode. The dual mode makes vi an attractive editor for users who separate text entry from editing. For users who edit as they type, the modeless editing of emacs can be more comfortable. However, vim supports both ways of editing, through the insertmode option and the evim command for invoking vim.
vi is based on an older line editor called ex. (ex, in turn, was developed by Bill Joy at the University of California, Berkeley, from the primordial Unix line editor, ed.) A user can invoke powerful editing capabilities within vi by typing a colon (:), entering an ex command, and pressing the ENTER key. Furthermore, you can place ex commands in a startup file called ~/.exrc, which vi reads at the beginning of your editing session. Because ex commands are such an important part of vi, they are also described in this chapter.
One of the most common versions of vi found on GNU/Linux systems is Bram Moolenaar's Vi IMproved, or vim. On some GNU/Linux distributions, vim is the default version of vi and runs when you invoke vi. vim offers many extra features, and optionally changes some of the basic features of vi, most notoriously changing the undo command to support multiple levels of undo.
Fully documenting vim is beyond the scope of this chapter, but we do cover some of its most commonly used options and features. Beyond what we cover here, vim offers enhanced support to programmers through an integrated build and debugging process, syntax highlighting, extended ctags support, and support for Perl and Python, as well as GUI fonts and menus, function key mapping, independent mapping for each mode, and more. Fortunately,
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
The three most common ways of starting a vi session are:

vi [options] file

vi [options] +num file

vi [options] +/pattern file

            
You can open file for editing, optionally at line num or at the first line matching pattern. If no file is specified, vi opens with an empty buffer.
Because vi and ex are the same program, they share the same options. However, some options only make sense for one version of the program. Options specific to vim are so marked.
+[ num ]
Start editing at line number num, or the last line of the file if num is omitted.
+/ pattern
Start editing at the first line matching pattern. (For ex, this fails if nowrapscan is set in your .exrc startup file, since ex starts editing at the last line of a file.)
-b
Edit the file in binary mode. {vim}
-c command
Run the given ex command upon startup. Only one -c option is permitted for vi; vim accepts up to 10. An older form of this option, + command, is still supported.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Review of vi Operations
Inhaltsvorschau
This section provides a review of the following:
  • vi modes
  • Syntax of vi commands
  • Status-line commands
Once the file is opened, you are in command mode . From command mode, you can:
  • Invoke insert mode
  • Issue editing commands
  • Move the cursor to a different position in the file
  • Invoke ex commands
  • Invoke a Unix shell
  • Save the current version of the file
  • Exit vi
In insert mode, you can enter new text in the file. You normally enter insert mode with the i command. Press the ESCAPE key to exit insert mode and return to command mode. The full list of commands that enter insert mode is provided later, in the section "Insert Commands."
In vi, editing commands have the following general form:

[n] operator [m] motion

               
The basic editing operators are:
c
Begin a change.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
vi Commands
Inhaltsvorschau
vi supplies a large set of single-key commands when in command mode. vim supplies additional multikey commands.
Some versions of vi do not recognize extended keyboard keys (e.g., arrow keys, Page Up, Page Down, Home, Insert, and Delete); some do. All, however, recognize the keys in this section. Many users of vi prefer to use these keys, as it helps them keep their fingers on the home row of the keyboard. A number preceding a command repeats the movement. Movement commands are also used after an operator. The operator works on the text that is moved.

Section 9.4.1.1: Character

h, j, k, l
Left, down, up, right (, , , ).
Spacebar
Right.
BACKSPACE
Left.
CTRL-H
Left.

Section 9.4.1.2: Text

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
vi Configuration
Inhaltsvorschau
This section describes the following:
  • The :set command
  • Options available with :set
  • Example .exrc file
The :set command allows you to specify options that change characteristics of your editing environment. Options may be put in the ~/.exrc file or set during a vi session.
The colon does not need to be typed if the command is put in .exrc:
:set x
Enable boolean option x, show value of other options.
:set no x
Disable option x.
:set x = value
Give value to option x.
:set
Show changed options.
:set all
Show all options.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
ex Basics
Inhaltsvorschau
The ex line editor serves as the foundation for the screen editor vi. Commands in ex work on the current line or on a range of lines in a file. Most often, you use ex from within vi. In vi, ex commands are preceded by a colon and entered by pressing ENTER.
You can also invoke ex on its own—from the command line—just as you would invoke vi. (You could execute an ex script this way.) Or you can use the vi command Q to quit the vi editor and enter ex.
To enter an ex command from vi, type:

                  :[address] command [options]
An initial : indicates an ex command. As you type the command, it is echoed on the status line. Execute the command by pressing the ENTER key. address is the line number or range of lines that are the object of command. options and addresses are described below. ex commands are described in the section "Alphabetical Summary of ex Commands."
You can exit ex in several ways:
:x
Exit (save changes and quit).
:q!
Quit without saving changes.
:vi
Switch to the vi editor on the current file.
If no address is given, the current line is the object of the command. If the address specifies a range of lines, the format is:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of ex Commands
Inhaltsvorschau
ex commands can be entered by specifying any unique abbreviation. In this listing, the full name appears in the margin, and the shortest possible abbreviation is used in the syntax line. Examples are assumed to be typed from vi, so they include the : prompt.
abbreviate

ab [string text]
Define string when typed to be translated into text. If string and text are not specified, list all current abbreviations.
Examples
Note: ^M appears when you type ^V followed by ENTER.

:ab ora O'Reilly Media, Inc.

:ab id Name:^MRank:^MPhone:
append
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 10: The sed Editor
Inhaltsvorschau
The sed "stream editor" is one of the most prominent Unix text processing tools. It is most often used for performing simple substitutions on data streams going through pipelines, but sed scripts can be written to do much more.
This chapter presents the following topics:
  • Conceptual overview of sed
  • Command-line syntax
  • Syntax of sed commands
  • Group summary of sed commands
  • Alphabetical summary of sed commands
Source code for GNU sed is available from ftp://ftp.gnu.org/gnu/sed/. The Free Software Foundation's home page for sed is http://www.gnu.org/software/sed/sed.html. For more information on sed, see sed & awk, listed in the Bibliography.
The stream editor, sed, is a noninteractive editor. It interprets a script and performs the actions in the script. sed is stream-oriented because, like many Unix programs, input flows through the program and is directed to standard output. For example, sort is stream-oriented; vi is not. sed's input typically comes from a file or pipe but it can also be taken from the keyboard. Output goes to the screen by default but can be captured in a file or sent through a pipe instead. GNU sed can edit files that use multibyte character sets.
  • Editing one or more files automatically.
  • Simplifying repetitive edits to multiple files.
  • Writing conversion programs.
sed operates as follows:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
The stream editor, sed, is a noninteractive editor. It interprets a script and performs the actions in the script. sed is stream-oriented because, like many Unix programs, input flows through the program and is directed to standard output. For example, sort is stream-oriented; vi is not. sed's input typically comes from a file or pipe but it can also be taken from the keyboard. Output goes to the screen by default but can be captured in a file or sent through a pipe instead. GNU sed can edit files that use multibyte character sets.
  • Editing one or more files automatically.
  • Simplifying repetitive edits to multiple files.
  • Writing conversion programs.
sed operates as follows:
  • Each line of input is copied into a "pattern space," an internal buffer where editing operations are performed.
  • All editing commands in a sed script are applied, in order, to each line of input.
  • Editing commands are applied to all lines (globally) unless line addressing restricts the lines affected.
  • If a command changes the input, subsequent commands and address tests are applied to the current line in the pattern space, not the original input line.
  • The original input file is unchanged because the editing commands modify an in-memory copy of each original input line. The copy is sent to standard output (but can be redirected to a file).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
The syntax for invoking sed has two forms:

    sed [-n] [-e] 'command' file(s)

    sed [-n]  -f  scriptfile file(s)

            
The first form allows you to specify an editing command on the command line, surrounded by single quotes. The second form allows you to specify a scriptfile, a file containing sed commands. Both forms may be used together, and they may be used multiple times. If no file (s) is specified, sed reads from standard input.
The following options are recognized:
-n
Suppress the default output; sed displays only those lines specified with the p command or with the p flag of the s command.
-e cmd
Next argument is an editing command. Necessary if multiple scripts or commands are specified.
-f file
Next argument is a file containing editing commands.
If the first line of the script is #n, sed behaves as if -n had been specified.
Multiple -e and -f options may be provided, and they may be mixed. The final script consists of the concatenation of all the script and file arguments.
GNU sed accepts a number of additional command-line options, as well as long-option equivalents for the standard options. The GNU sed options are:
-e cmd, --expression
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Syntax of sed Commands
Inhaltsvorschau
sed commands have the general form:

    [address [,address ]][!]command [arguments]
commands consist of a single letter or symbol; they are described later, by group and alphabetically. arguments include the label supplied to b or t, the filename supplied to r or w, and the substitution flags for s. addresses are described below.
A sed command can specify zero, one, or two addresses. In POSIX sed, an address has one of the forms in the following table. Regular expressions are described in Chapter 7. Additionally, \n can be used to match any newline in the pattern space (resulting from the N command), but not the newline at the end of the pattern space.
Address
Meaning
/ pattern /
Lines that match pattern.
\; pattern ;
Like previous, but use semicolon as the delimiter instead of slash. Any character may be used. This is useful if pattern contains multiple slash characters.
N
Line number N.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Group Summary of sed Commands
Inhaltsvorschau
In the lists that follow, the sed commands are grouped by function and are described tersely. Full descriptions, including syntax and examples, can be found in the following section, "Alphabetical Summary." Commands marked with a | are specific to GNU sed.
a\
Append text after a line.
c\
Replace text (usually a text block).
i\
Insert text before a line.
d
Delete lines.
s
Make substitutions.
y
Translate characters (like Unix tr).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of sed Commands
Inhaltsvorschau
GNU sed lets you use the filenames /dev/stdin, /dev/stdout, and /dev/stderr to refer to standard input, output, and error respectively for the r, R, w, and W commands and the w flag to the s command.
GNU-specific commands or extensions are noted with {G} in the command synopsis. When the GNU version allows a command to have two addresses, the command is performed for each input line within the range.
#

#
Begin a comment in a sed script. Valid only as the first character of the first line. (Some versions, including GNU sed, allow comments anywhere, but it is better not to rely on this.) If the first line of the script is #n, sed behaves as if -n had been specified.
:

:label

                  
Label a line in the script for the transfer of control by b or t. According to POSIX, sed must support labels that are unique in the first eight characters. GNU sed has no limit, but some older versions only support up to seven characters.
=

[/pattern/]=

[address1[,address2]]= {G}

                  
Write to standard output the line number of each line addressed by pattern.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 11: The awk Programming Language
Inhaltsvorschau
The awk programming language is often used for text and string manipulation within shell scripts, particularly when input data can be viewed as records and fields. However, it is also an elegant and capable programming language that allows you to accomplish a lot with very little work.
This chapter presents the following topics:
  • Conceptual overview
  • Command-line syntax
  • Patterns and actions
  • Built-in variables
  • Operators
  • Variables and array assignment
  • User-defined functions
  • gawk-specific facilities
  • Implementation limits
  • Group listing of awk functions and commands
  • Alphabetical summary of awk functions and commands
  • Source code
For more information, see sed & awk and Effective awk Programming, listed in the Bibliography.
awk is a pattern-matching program for processing files, especially when each line has a simple field-oriented layout. The new version of awk, called nawk, provides additional capabilities. Every modern Unix system comes with a version of new awk, and its use is recommended over old awk. The GNU version of awk, called gawk, implements new awk and provides a number of additional features.
Different systems vary in what new and old awk are called. Some have oawk and awk, for the old and new versions, respectively. Others have awk and nawk. Still others only have awk, which is the new version. This example shows what happens if your awk is the old one:

    $ 
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
awk is a pattern-matching program for processing files, especially when each line has a simple field-oriented layout. The new version of awk, called nawk, provides additional capabilities. Every modern Unix system comes with a version of new awk, and its use is recommended over old awk. The GNU version of awk, called gawk, implements new awk and provides a number of additional features.
Different systems vary in what new and old awk are called. Some have oawk and awk, for the old and new versions, respectively. Others have awk and nawk. Still others only have awk, which is the new version. This example shows what happens if your awk is the old one:

    $ awk 1 /dev/null

    awk: syntax error near line 1

    awk: bailing out near line 1
awk will exit silently if it is the new version.
The POSIX standard for awk is based on new awk, and the standard uses the simple designation awk for that language. Thus, we do also. If your system's awk is the old one, find the new one, and use it for your programs.
Solaris is the only modern Unix system that persists in having old awk as the default version. You should be sure to put /usr/xpg4/bin in your shell's search path before /usr/bin, so that you will get a POSIX-compliant version of awk. Alternatively, just install the GNU version.
Items described here as "common extensions" are often available in different versions of new awk, as well as in gawk, but should not be used if strict portability of your programs is important to you.
The freely available versions of awk described in the section "Source Code," later in this chapter, all implement new awk.
With awk, you can:
  • Think of a text file as made up of records and fields in a textual database.
  • Perform arithmetic and string operations.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
The syntax for invoking awk has two forms:

    awk  [options]  'script'  var=value  file(s)

    awk  [options]  -f scriptfile  var=value  file(s)

            
You can specify a script directly on the command line, or you can store a script in a scriptfile and specify it with -f. POSIX awk allows multiple -f scripts. Variables can be assigned a value on the command line. The value can be a string or numeric constant, a shell variable ($ name), or a command substitution (' cmd '), but the value is available only after the BEGIN statement is executed.
awk operates on one or more files. If none are specified (or if - is specified), awk reads from the standard input.
The standard options are:
-F fs
Set the field separator to fs. This is the same as setting the built-in variable FS. POSIX awk allows fs to be a regular expression. Each input line, or record, is divided into fields by white space (spaces or TABs) or by some other user-definable field separator. Fields are referred to by the variables $1, $2,..., $ n. $0 refers to the entire record.
-v var = value
Assign a value to variable var. This allows assignment before the script begins execution.
For example, to print the first three (colon-separated) fields of each record on separate lines:

    awk -F: '{ print $1; print $2; print $3 }' /etc/passwd
Many examples are shown later in the section "Simple Pattern-Action Examples."
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Patterns and Procedures
Inhaltsvorschau
awk scripts consist of patterns and actions :

               pattern  { action }
Both are optional. If pattern is missing, { action } is applied to all lines. If { action } is missing, the matched line is printed.
A pattern can be any of the following:

                  general expression

    /regular expression/

    relational expression

                  pattern-matching expression

    BEGIN

    END
  • General expressions can be composed of quoted strings, numbers, operators, function calls, user-defined variables, or any of the predefined variables described later in the section "Built-in Variables."
  • Regular expressions use the extended set of metacharacters as described in Chapter 7.
  • The ^ and $ metacharacters refer to the beginning and end of a string (such as the fields), respectively, rather than the beginning and end of a line. In particular, these metacharacters will not match at a newline embedded in the middle of a string.
  • Relational expressions use the relational operators listed in the section "Operators," later in this chapter. For example, $2 > $1 selects lines for which the second field is greater than the first. Comparisons can be either string or numeric. Thus, depending upon the types of data in $1 and $2, awk will do either a numeric or a string comparison. This can change from one record to the next.
  • Pattern-matching expressions use the operators ~ (matches) and !~ (doesn't match). See the section "Operators" later in this chapter.
  • The BEGIN pattern lets you specify actions that take place
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Built-in Variables
Inhaltsvorschau
All awk variables are included in gawk.
Version
Variable
Description
awk
ARGC
Number of arguments on the command line.
ARGV
An array containing the command-line arguments, indexed from 0 to ARGC - 1.
CONVFMT
String conversion format for numbers ("%.6g"). (POSIX)
ENVIRON
An associative array of environment variables.
FILENAME
Current filename.
FNR
Like NR, but relative to the current file.
FS
Field separator (a space).
NF
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Operators
Inhaltsvorschau
The following table lists the operators , in order of increasing precedence, that are available in awk.
Symbol
Meaning
= += -= *= /= %= ^= **=
Assignment
?:
C conditional expression
||
Logical OR (short-circuit)
&&
Logical AND (short-circuit)
in
Array membership
~ !~
Match regular expression and negation
< <= > >= != ==
Relational operators
(blank)
Concatenation
+ -
Addition, subtraction
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Variable and Array Assignment
Inhaltsvorschau
Variables can be assigned a value with an = sign. For example:

    FS = ","
Expressions using the operators +, -, /, and % (modulo) can be assigned to variables.
Arrays can be created with the split() function (described later), or they can simply be named in an assignment statement. Array elements can be subscripted with numbers (array [1], ..., array [ n ]) or with strings. Arrays subscripted by strings are called associative arrays. For example, to count the number of widgets you have, you could use the following script:

    /widget/ { count["widget"]++ }       Count widgets

    END      { print count["widget"] }   Print the count

            
You can use the special for loop to read all the elements of an associative array:

    for (item in array)

            process array[item]
The index of the array is available as item, while the value of an element of the array can be referenced as array[item].
You can use the in operator to test that an element exists by testing to see if its index exists. For example:

    if (index in array)

            ...
tests that array[index] exists, but you cannot use it to test the value of the element referenced by array[index].
You can also delete individual elements of the array using the delete statement. (See also the delete entry in the section "Alphabetical Summary of awk Functions and Commands," later in this chapter.)
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
User-Defined Functions
Inhaltsvorschau
POSIX awk allows you to define your own functions. This makes it easy to encapsulate sequences of steps that need to be repeated into a single place, and reuse the code from anywhere in your program.
The following function capitalizes each word in a string. It has one parameter, named input, and five local variables that are written as extra parameters:

    # capitalize each word in a string

    function capitalize(input,    result, words, n, i, w)

    {

       result = ""

       n = split(input, words, " ")

       for (i = 1; i <= n; i++) {

            w = words[i]

            w = toupper(substr(w, 1, 1)) substr(w, 2)

            if (i > 1)

                     result = result " "

            result = result w

       }

       return result

    }



    # main program, for testing

    { print capitalize($0) }
With this input data:

    A test line with words and numbers like 12 on it.
This program produces:

    A Test Line With Words And Numbers Like 12 On It.
For user-defined functions, no space is allowed between the function name and the left parenthesis when the function is called.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Gawk-Specific Features
Inhaltsvorschau
This section describes features unique to gawk .
gawk allows you to open a two-way pipe to another process, called a coprocess. This is done with the |& operator used with getline and print or printf.

    print database command |& "db_server"

    "db_server" |& getline response
If the command used with |& is a filename beginning with /inet/, gawk opens a TCP/IP connection. The filename should be of the following form:

    /inet/protocol/lport/hostname/rport

               
The parts of the filename are:
protocol
One of tcp, udp, or raw, for TCP, UDP, or raw IP sockets, respectively. Note: raw is currently reserved but unsupported.
lport
The local TCP or UPD port number to use. Use 0 to let the operating system pick a port.
hostname
The name or IP address of the remote host to connect to.
rport
The port (application) on the remote host to connect to. A service name (e.g., tftp) is looked up using the C getservbyname() function.
When gawk is built and installed, a separate program named
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Implementation Limits
Inhaltsvorschau
Many versions of awk have various implementation limits , on things such as:
  • Number of fields per record
  • Number of characters per input record
  • Number of characters per output record
  • Number of characters per field
  • Number of characters per printf string
  • Number of characters in literal string
  • Number of characters in character class
  • Number of files open
  • Number of pipes open
  • The ability to handle 8-bit characters and characters that are all zero (ASCII NUL)
gawk does not have limits on any of the above items, other than those imposed by the machine architecture and/or the operating system.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Group Listing of awk Functions and Commands
Inhaltsvorschau
The following table classifies awk functions and commands.
Function type
Functions or commands
a Available in gawk.
b Available in Bell Labs awk and gawk.
Arithmetic
atan2
cos
exp
int
log
rand
sin
sqrt
srand
String
asort a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of awk Functions and Commands
Inhaltsvorschau
The following alphabetical list of keywords and functions includes all that are available in POSIX awk and gawk. Extensions that aren't part of POSIX awk but that are in both gawk and the Bell Laboratories awk are marked as {E}. Cases where gawk has extensions are marked as {G}. Items that aren't marked with a symbol are available in all versions.
#

#
Ignore all text that follows on the same line. # is used in awk scripts as the comment character and is not really a command.
and

and(expr1, expr2) {G}

                  
Return the bitwise AND of expr1 and expr2, which should be values that fit in a C unsigned long.
asort

asort(src [,dest]) {G}

                  
Sort the array src based on the element values, destructively replacing the indices with values from one to the number of elements in the array. If
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Output Redirections
Inhaltsvorschau
For print and printf, dest-expr is an optional expression that directs the output to a file or pipe.
> file
Directs the output to a file, overwriting its previous contents.
>> file
Appends the output to a file, preserving its previous contents. In both of these cases, the file will be created if it does not already exist.
| command
Directs the output as the input to a system command.
|& command
Directs the output as the input to a coprocess. gawk only.
Be careful not to mix > and >> for the same file. Once a file has been opened with >, subsequent output statements continue to append to the file until it is closed.
Remember to call close() when you have finished with a file, pipe, or coprocess. If you don't, eventually you will hit the system limit on the number of simultaneously open files.
Format specifiers for printf and sprintf have the following form:

    %[posn$][flag][width][.precision]letter
The control letter is required. The format conversion control letters are given in the following table.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Source Code
Inhaltsvorschau
The following URLs indicate where to get source code for four freely available versions of awk, and for GNU gettext .
http://cm.bell-labs.com/~bwk
Brian Kernighan's home page, with links to the source code for the latest version of awk from Bell Laboratories.
ftp://ftp.whidbey.net/pub/brennan/mawk1.3.3.tar.gz
Michael Brennan's mawk . A very fast, very robust version of awk.
ftp://ftp.gnu.org/gnu/gawk/
The Free Software Foundation's version of awk, called gawk.
http://www.gnu.org/software/gawk/gawk.html
The Free Software Foundation's home page for gawk.
http://awka.sourceforge.net
The home page for awka, a translator that turns awk programs into C, compiles the generated C, and then links the object code with a library that performs the core awk functions.
ftp://ftp.gnu.org/gnu/gettext/
The source code for GNU gettext. Get this if you need to produce translations for your awk programs that use gawk.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 12: Source Code Management: An Overview
Inhaltsvorschau
The following chapters describe three popular source code management systems for Unix. This chapter introduces the major concepts involved with using these systems for users who may never have used one. If you're already familiar with source code management, feel free to skip ahead to the particular software suite that interests you. See also the related books in the Bibliography.
This chapter covers the following topics:
  • Introduction and terminology
  • Usage models
  • Unix source code management systems
  • Other source code management systems
Source code management systems let you store and retrieve multiple versions of a file. While originally designed for program source code, they can be used for any kind of file: source code, documentation, configuration files, and so on. Modern systems allow you to store binary files as well, such as image or audio data.
Source code management systems let you compare different versions of a file, as well as do "parallel development." In other words, you can work on two different versions of a file at the same time, with the source code management system storing both versions. You can then merge changes from two versions into a third version. This will become more clear shortly. We'll start by defining some terms.
Repository
A repository is where the source code management system stores its copy of your file. Usually one Unix file is used to hold all the different versions of a source file. Each source code management system uses its own format to allow it to retrieve different versions easily, and to track who made what changes, and when.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Introduction and Terminology
Inhaltsvorschau
Source code management systems let you store and retrieve multiple versions of a file. While originally designed for program source code, they can be used for any kind of file: source code, documentation, configuration files, and so on. Modern systems allow you to store binary files as well, such as image or audio data.
Source code management systems let you compare different versions of a file, as well as do "parallel development." In other words, you can work on two different versions of a file at the same time, with the source code management system storing both versions. You can then merge changes from two versions into a third version. This will become more clear shortly. We'll start by defining some terms.
Repository
A repository is where the source code management system stores its copy of your file. Usually one Unix file is used to hold all the different versions of a source file. Each source code management system uses its own format to allow it to retrieve different versions easily, and to track who made what changes, and when.
Sandbox
A sandbox is your personal, so-called "working copy" of the program or set of documents under development. You edit your private copy of the file in your own sandbox, returning changes to the source code management system when you're satisfied with the new version.
Check in, check out
You "check out" files from the repository, edit them, and then "check them in" when you're satisfied with your changes. Other developers working against the same repository will not see your changes until after you check them back in. Another term used for check-in is
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Usage Models
Inhaltsvorschau
Different systems have different conceptual "models" as to how they're used.
Older systems such as SCCS and RCS use a "check out with locking" model. These systems were developed before client/server computing, when software development was done on centralized minicomputers and mainframes. In this model, the repository is a central directory on the same machine where the developers work, and each developer checks out a private copy into their own sandbox. In order to avoid two developers making conflicting changes to a file, the file must be locked when it's checked out. Only one user may lock a particular version of a file at a time. When that user has checked in their changes, they unlock the file so that the next user can check in changes. If necessary, the second user may "break" the first user's lock, in which case the first user is notified via electronic mail.
This model works well for small projects where developers are co-located and can communicate easily. As long as one developer locks a file when she checks it out, another developer wishing to work with the file will know that he can't until the first one is done. The drawback is that such locking can slow down development significantly.
Newer systems, such as CVS and Subversion, use a "copy, modify, merge" model. In practice, when two developers wish to work on the same file, they usually end up changing different, unrelated parts of the file. Most of the time each developer can make changes without adversely affecting the other. Thus, files are not locked upon checkout into a sandbox. Instead, the source code management system detects conflicts and disallows a check-in when conflicts exist.
For example, consider two developers, dangermouse and penfold, who are both working on whizprog.c. They each start with version 1.4 of the file. dangermouse commits his changes, creating version 1.5. Before penfold
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Unix Source Code Management Systems
Inhaltsvorschau
There are several source code management systems for Unix .
Source Code Control System (SCCS)
SCCS is the original Unix source code management system. It was developed in the late 1970s for the Programmer's Workbench (PWB) Unix systems within Bell Labs. It is still in use at a few large long-time Unix sites. However, for a long time it was not available as a standard part of most commercial or BSD Unix systems, and it did not achieve the wide-spread popularity of other, later systems. (It is still available with Solaris.) SCCS uses a file storage format that allows it to retrieve any version of a source file in constant time.
Revision Control System (RCS)
RCS was developed in the early 1980s at Purdue University by Walter F. Tichy. It became popular in the Unix world when it was shipped with 4.2 BSD in 1983. At the time, Berkeley Unix was the most widely-used Unix variant, even though to get it a site had to have a Unix license from AT&T.
RCS is easier to use than SCCS. Although it has a number of related commands, only three or four are needed for day-to-day use, and they are quickly mastered. A central repository is easy to use: you first create a directory for the sandbox. In the sandbox, you make a symbolic link to the repository named RCS, and then all the developers can share the repository. RCS uses a file format that is optimized for retrieving the most recent version of a file.
Concurrent Versions System (CVS)
CVS was initially built as a series of shell scripts sitting atop RCS. Later it was rewritten in C for robustness, although still using RCS commands to manage the storage of files. However, for quite some time, CVS has had the RCS functionality built into it, and no longer requires that RCS be available. The file format continues to be the same. CVS was the first distributed source code management system, and is currently the standard one for Unix systems, and in particular for collaborative, distributed, Free, and Open Source development projects.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Other Source Code Management Systems
Inhaltsvorschau
Besides the source code management systems covered in this book, several other systems are worth knowing about. The following list, though, is by no means exhaustive.
Arch
GNU Arch is a distributed source code management system similar to CVS and Subversion. One of its significant strengths is that you can do off-line development with it, working on multiple versions even on systems that are not connected to the Internet and that cannot communicate with the central repository. For more information, see http://www.gnu.org/software/gnu-arch/.
Codeville
Codeville is a distributed version control system in the early stages of development. It is written in Python, is easy to set up and use, and shows a lot of promise. For more information, see http://codeville.org/.
CSSC
CSSC is a free clone of SCCS. It intends to provide full compatibility with SCCS, including file format, command names and options, and "bug for bug" compatible behavior. If you have an existing SCCS repository, you should be able to drop CSSC into your environment, in place of SCCS. CSSC can be used to migrate from a commercial Unix system to a freely available clone, such as GNU/Linux or a BSD system. For more information, see http://directory.fsf.org/GNU/CSSC.html.
Monotone
The web page for monotone describes it well:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 13: The Revision Control System
Inhaltsvorschau
The Revision Control System (RCS ) provides a series of commands for maintaining multiple versions of files. It can manage both textual and binary data. While primarily used for software development, RCS can manage other files as well: documentation, textual databases, and so on.
This chapter presents the following topics:
  • Overview of commands
  • Basic operation
  • General RCS specifications
  • Alphabetical summary of commands
The Revision Control System (RCS) is designed to keep track of multiple file revisions, thereby reducing the amount of storage space needed. With RCS you can automatically store and retrieve revisions, merge or compare revisions, keep a complete history (or log) of changes, and identify revisions using symbolic keywords. RCS preserves execute permission on the files it manages, and you can store binary data in RCS files.
RCS is not a standard part of Solaris. It can be obtained from the Free Software Foundation (see http://www.gnu.org/software/rcs/). It typically does come with GNU/Linux and Mac OS X. The Official RCS Homepage may be found at http://www.cs.purdue.edu/homes/trinkle/RCS/. This chapter describes RCS Version 5.7.
For more information, see Applying RCS and SCCS, listed in the Bibliography.
The three most important RCS commands are:
ci
Check in revisions (put a file under RCS control).
co
Check out revisions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Overview of Commands
Inhaltsvorschau
The three most important RCS commands are:
ci
Check in revisions (put a file under RCS control).
co
Check out revisions.
rcs
Set up or change attributes of RCS files.
Two commands provide information about RCS files:
ident
Extract keyword values from an RCS file.
rlog
Display a summary (log) about the revisions in an RCS file.
You can compare RCS files with these commands:
merge
Incorporate changes from two files into a third file.
rcsdiff
Report differences between revisions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Basic Operation
Inhaltsvorschau
Normally, you maintain RCS files in a subdirectory called RCS, so the first step in using RCS should be:

    mkdir RCS
Next, you place an existing file (or files) under RCS control by running the check-in command:

    ci file

            
This creates a file called file ,v in the RCS directory. file ,v is called an RCS file, and it stores all future revisions of file. When you run ci on a file for the first time, you are prompted to describe the contents. ci then deposits file into the RCS file as revision 1.1.
To edit a new revision, check out a copy:

    co -l file

            
This causes RCS to extract a copy of file from the RCS file. You must lock the file with -l to make it writable by you. This copy is called a working file. When you're done editing, you can record the changes by checking the working file back in again:

    ci file

            
This time, you are prompted to enter a log of the changes made, and the file is deposited as revision 1.2. Note that a check-in normally removes the working file. To retrieve a read-only copy, do a check-out without a lock:

    co file

            
This is useful when you need to keep a copy on hand for compiling or searching. As a shortcut to the previous ci/co, you could type:

    ci -u file

            
This checks in the file but immediately checks out a read-only ("unlocked") copy. In practice, you would probably make a "checkpoint" of your working version and then keep going, like this:

    ci -l file

            
This checks in the file, and then checks it back out again, locked, for continued work. To compare changes between a working file and its latest revision, you can type:

    rcsdiff file

            
Another useful command is rlog, which shows a summary of log messages. System administrators can use the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
General RCS Specifications
Inhaltsvorschau
This section discusses:
  • Keyword substitution
  • Keywords
  • Example values
  • Revision numbering
  • Specifying the date
  • Specifying states
  • Standard options and environment variables
RCS lets you place keyword variables in your working files. These variables are later expanded into revision notes. You can then use the notes either as embedded comments in the input file or as text strings that appear when the output is printed. To create revision notes via keyword substitution , follow this procedure:
  1. In your working file, type any of the keywords listed below.
  2. Check the file in.
  3. Check the file out again. Upon checkout, the co command expands each keyword to include its value. That is, co replaces instances of:
    
                            $
    
                            keyword
    
                            $
    
                         
    with:
    
                            $
    
                            keyword
    
                            :
    
                            value 
    
                            $.
    
    
  4. Subsequent check-in and check-out of a file updates any existing keyword values. Unless otherwise noted below, existing values are replaced by new values.
Many commands have a -k option that provides considerable flexibility during keyword substitution.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Commands
Inhaltsvorschau
For details on the syntax of keywords, revision numbers, dates, states, and standard options, refer to the previous discussions.
ci

ci [options] files

                  
Check in revisions. ci stores the contents of the specified working files into their corresponding RCS files. Normally, ci deletes the working file after storing it. If no RCS file exists, the working file is an initial revision. In this case, the RCS file is created, and you are prompted to enter a description of the file. If an RCS file exists, ci increments the revision number and prompts you to enter a message that logs the changes made. If a working file is checked in without changes, the file reverts to the previous revision.
The two mutually exclusive options -u and -l, along with -r, are the most common. Use -u to keep a read-only copy of the working file (for example, so the file can be compiled or searched). Use -l to update a revision and then immediately check it out again with a lock. This allows you to save intermediate changes but continue editing (for example, during a long editing session). Use -r to check in a file with a different release number. ci accepts the standard options -q, -V, -V n, -T, -x, and -z.
Options
-d[ date ]
Check the file in with a timestamp of date or, if no date is specified, with the time of last modification.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 14: The Concurrent Versions System
Inhaltsvorschau
This chapter is a comprehensive reference of all CVS commands, with a brief summary of what each does. It is intended to be useful as a quick reference, not as a tutorial.
This chapter covers the following topics:
  • Conceptual overview
  • Command-line syntax and options
  • CVS dot files
  • Environment variables
  • Keywords and keyword modes
  • Dates
  • CVSROOT variables
  • Alphabetical summary of commands
Most of the material in this chapter is adapted from Essential CVS, which is cited in the Bibliography. See that book for much more information on CVS. The Internet starting point for CVS is http://www.cvshome.org/.
The basic concepts for source code management systems were presented earlier in Chapter 12. As described there, CVS is a distributed source code management system based on the "copy, modify, merge" model. It uses RCS format files for storing data in its repository and is currently the most popular source code management suite for Unix and Unix-like systems.
Table 14-1 is a quick-start guide to using CVS. You would use the commands in the order shown to create and start using a CVS repository. (The basic steps for the Subversion source code management system are shown in more detail in the section "Using Subversion: A Quick Tour" in Chapter 15. Using CVS is similar.)
Table 14-1: CVS commands quick-start guide
Command
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
The basic concepts for source code management systems were presented earlier in Chapter 12. As described there, CVS is a distributed source code management system based on the "copy, modify, merge" model. It uses RCS format files for storing data in its repository and is currently the most popular source code management suite for Unix and Unix-like systems.
Table 14-1 is a quick-start guide to using CVS. You would use the commands in the order shown to create and start using a CVS repository. (The basic steps for the Subversion source code management system are shown in more detail in the section "Using Subversion: A Quick Tour" in Chapter 15. Using CVS is similar.)
Table 14-1: CVS commands quick-start guide
Command
Purpose
mkdir /path/to/repos
Make the repository directory.
cvs init /path/to/repos
Initialize the repository.
cvs import ...
Import the initial version of a project into the repository.
cvs checkout ...
Create a sandbox.
cvs diff ...
Compare the sandbox to the repository, or different versions in the repository.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax and Options
Inhaltsvorschau
CVS supports a number of command-line options that you can use to control various aspects of CVS behavior. Each CVS subcommand has its own options, as well.
The syntax of any CVS command is as follows:

    cvs [cvs-options] [command] [command-options-and-arguments]
The cvs-options modify the behavior of the main CVS code, rather than the code for a specific command.
Options to the cvs command are supplied before the particular subcommand to be executed. This section focuses on options that you pass to the cvs executable itself, not to any specific CVS command. The following options are valid:
-a
Authenticate all network traffic. Without this option, the initial connection for the command is authenticated, but later traffic along the same data stream is assumed to be from the same source.
This option is available only with GSS-API connections, but if you use ssh as your rsh replacement in the ext connection mode, ssh authenticates the data stream.
This option is supported if it is listed in cvs --help-options. The command-line client can be compiled to support it by using the --enable-client option to the configure script.
--allow-root= directory
Used as part of the inetd command string for the server, kserver, and pserver connection methods. The directory is the repository root directory that the server allows connections to. Using --allow-root more than once in a command allows users to connect to any of the specified repositories.
-d
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Dot Files
Inhaltsvorschau
In client/server mode, all the dot files other than .rhosts should be on the client computer. The .rhosts file should be in the user's home directory on the server computer.
These are the dot files in the sandbox directory:
.cvsignore
Contains a list of files CVS should not process. The format is one or more lines, with whitespace-separated filenames or shell wildcard patterns matching files that CVS should ignore when producing informational messages, and during commit, update, or status operations. A single ! causes CVS to empty out its ignore list and start over again with subsequent filenames or patterns. The file may be checked into CVS.
.# filename . revision
If a project file that is not fully synchronized with the repository is overwritten by CVS, the original file is stored as .# filename . revision, where revision is the BASE revision of the file.
These are the dot files in a user's home directory:
.cvsignore
Contains a list of files CVS should not process. See the earlier description.
.cvspass
Used in pserver remote-access mode. This file contains the user's password for each repository the user is logged into, stored in a simple form of encoding. Be aware that the file is human-readable and that the passwords are easy to decrypt.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Environment Variables
Inhaltsvorschau
Several environment variables affect CVS. Some are read only when CVS is the client, and some are read only when CVS is the server. When the repository resides on the local machine, both sets are read.
The environment variables in the following list are read and used by the process that runs on the client computer and must be in the calling user's environment:
CVS_CLIENT_LOG
Used for debugging CVS in client/server mode. If set, everything sent to the server is stored in the $CVS_CLIENT_LOG.in file, and everything received by the client is stored in $CVS_CLIENT_LOG.out.
CVS_CLIENT_PORT
Used to set the port the client uses to connect to the CVS server in kserver, gserver, and pserver modes. By default, the client uses port 2401 (gserver and pserver) or port 1999 (kserver) to connect to the server.
CVSIGNORE
A whitespace-separated list of filename patterns that should be ignored. See the description of the .cvsignore file, earlier in this chapter.
CVSEDITOR, EDITOR, VISUAL
Used to set the editor CVS calls when it opens an editor for log messages. On Unix and GNU/Linux systems, the default editor is vi. Using CVSEDITOR is preferred over EDITOR and VISUAL, as other variables may be used by other programs.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Keywords and Keyword Modes
Inhaltsvorschau
CVS contains keywords that can be included in nonbinary project files. When CVS finds a keyword in a file it is checking out, it expands the keyword to provide metadata about the latest revision of the file. You can set keyword-expansion modes on a file to tell CVS whether (and how) to expand the keywords it finds.
Keyword-expansion modes also control line-ending conversion. Unix, Macintosh, and Windows operating systems use different sets of codes to signal the ends of lines. (GNU/Linux uses the same codes as Unix.) When you commit a file from an operating system that doesn't use Unix line endings, CVS converts the line endings to Unix style. If you are storing binary files, this conversion can corrupt the file. Use the -kb keyword-expansion mode to tell CVS not to convert line endings.
CVS keywords take the form:

    $Keyword$
All keywords except Log expand to the format:

    $Keyword: value$
These are the keywords and the information they show about the file they are in:
Author
The username of the user who committed the last revision.
Date
The date on which the last revision was committed, in UTC.
Header
A header containing information about the file, including the author, date and revision number, path and filename of the RCS file (project file in the repository), file status, and whether the file is locked.
Id
A header like the one given by the Header keyword, without the path of the RCS file.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Dates
Inhaltsvorschau
In CVS, all dates and times are processed by a version of the GNU getdate function, which can translate dates and times given in several different formats. Case is always irrelevant when interpreting dates. Spaces are permitted in date strings, but in the command-line client a string with spaces should be surrounded by quotes. If a year is 0 to 99, it is considered to be in the twentieth century.
If a time is not given, midnight at the start of the date is assumed. If a time zone is not specified, the date is interpreted as being in the client's local time zone.
The legal time and date formats for CVS are defined by the ISO 8601 standard and RFC 822 as amended by RFC 1123. Other formats can be interpreted, but CVS is designed to handle only these standards.

Section 14.6.1.1: ISO 8601

The basic ISO 8601 date format is as follows:

                     year-month-day hours:minutes:seconds

                  
All values are numbers with leading zeros to ensure that the correct number of digits are used. Hours are given in 24-hour time. This produces the structure YYYY-MM-DD HH:MM:SS, which is internationally acceptable and can be sorted easily. You can use a date, a time, or both.
If you're using ISO 8601 format with the hyphens, the full date is required in CVS. The YYYYMMDD date format is also acceptable and can be abbreviated to YYYYMM or YYYY.
The HH and HH:MM time formats are acceptable. Times can also be specified without the colon, so HHMMSS or HHMM are usable.
Be aware that HHMM may be misinterpreted as YYYY. Get into the habit of using separators.
In strict ISO 8601 format, a T is required between the date and the time, but CVS understands this format with or without the T. The ISO 8601 standard also states that a Z at the end of the string designates UTC (Universal Coordinated Time), but CVS does not recognize the use of
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
CVSROOT Variables
Inhaltsvorschau
The administrative files in CVSROOT can use several types of variables: internal, environment, and shell variables. You can use these variables to pass parameters to the scripts in the scripting files, or you can use them as part of command-line templates.
The internal variables allow you to use information CVS stores about the currently running command. The environment variables are used to access information from the environment the command is running in, and the shell variables are used to access information about the shell.
Three environment variables are set when CVS runs commands or scripts from CVS administrative files:
CVS_USER
This variable is meaningful only with the pserver access method. It refers to the CVS username provided in the leftmost field of the appropriate line in CVSROOT/passwd. If this username does not exist, the variable expands to an empty string.
LOGNAME, USER
Both of these variables contain the username of the user calling the CVS process.
In the pserver access method, the username is the third field of the line in passwd. If no username is there, the CVS_USER value is used.
The syntax for referencing a CVS internal variable is ${VARIABLE}. The $VARIABLE syntax can also be used if the character immediately following the variable is neither alphanumeric nor an underscore (_).
These are the internal CVS variables:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of Commands
Inhaltsvorschau
Most of your interaction with CVS is through the various CVS subcommands. Even if you use a graphical client, most of the functions the client uses call the CVS subcommands.
Most subcommands have a shortened nickname that you can type instead of the longer subcommand name. These are called command synonyms in CVS jargon.
add

cvs [cvs-options] add [-k mode] [-m message] files

                  
Add a file or directory to the repository. This command can also be used to undo an uncommitted file deletion or to restore a deleted file. You must commit any added files in order for the addition to fully take effect.
Synonyms: ad, new.
Standard subcommand options: -k, -m.
Example

    $ cvs add Design.rtf

    cvs server: scheduling file 'Design.rtf' for addition

    cvs server: use 'cvs commit' to add this file permanently
admin

cvs [cvs-options] admin [options] [files ...]
Use RCS commands on the repository copy of project files. This command is a frontend for a range of useful (though sometimes useless to CVS) RCS-based commands. Project files are stored in the repository in RCS format, so it is useful to have a way to use some of the RCS commands on the files directly.
Synonyms: adm, rcs.
Standard subcommand options: -k.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 15: The Subversion Version Control System
Inhaltsvorschau
The Subversion version control system is a powerful Open Source system for management of file and directory versions. Designed from the ground up to support distributed development, it offers many leading-edge features.
This chapter covers the following topics:
  • Conceptual overview
  • Obtaining Subversion
  • Using Subversion: a quick tour
  • The Subversion command line client: svn
  • Repository administration: svnadmin
  • Examining the repository: svnlook
  • Providing remote access: svnserve
  • Other Subversion components
Most of the material in this chapter is adapted from Version Control with Subversion, which is cited in the Bibliography. See that book for much more information on Subversion.
Subversion is a version control system. It lets you track changes to an entire project directory tree. Every change made to the tree is recorded and can be retrieved.
Subversion is intended to be "a better CVS;" this is discussed in detail shortly. Subversion is purposely an Open Source project. If you want to participate, you can!
Actual data is kept in a repository, a set of directories and files managed by Subversion . Users use the svn client program to access the repository and make changes to it.
Subversion uses the copy-modify-merge development model. You make a private copy of a given project in a sandbox . (This is often called checking out a copy.) Like CVS and unlike RCS, this private copy is not locked in the repository. You then make all the changes you like to the copy within the sandbox, without having to worry about what other developers are doing. As you work, you can compare your changes to the version you started with, as well as to the version currently in the repository. Once you're satisfied with the changes, you
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
Subversion is a version control system. It lets you track changes to an entire project directory tree. Every change made to the tree is recorded and can be retrieved.
Subversion is intended to be "a better CVS;" this is discussed in detail shortly. Subversion is purposely an Open Source project. If you want to participate, you can!
Actual data is kept in a repository, a set of directories and files managed by Subversion . Users use the svn client program to access the repository and make changes to it.
Subversion uses the copy-modify-merge development model. You make a private copy of a given project in a sandbox . (This is often called checking out a copy.) Like CVS and unlike RCS, this private copy is not locked in the repository. You then make all the changes you like to the copy within the sandbox, without having to worry about what other developers are doing. As you work, you can compare your changes to the version you started with, as well as to the version currently in the repository. Once you're satisfied with the changes, you commit them, sometimes referred to as a check-in. (These terms come from RCS and CVS.)
In the event that another developer has modified part of a file that you were working on and checked it in, when you commit your changes Subversion notices, and indicates that a conflict exists. Conflicts are marked as such in the file, and Subversion creates pristine copies of the file as it exists in the repository and of the file as you modified it, so that you can do full comparisons. Once you have resolved the conflict, you tell Subversion about it, and then commit the final version.
Like CVS, Subversion lets you create a development branch , a separate stream of development versions. You can periodically merge changes from the main development stream (the trunk) into your branch, and also merge changes from your branch back into the trunk.
Finally, you can
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Obtaining Subversion
Inhaltsvorschau
The Subversion project web site is http://subversion.tigris.org/. It contains links to project documentation, Frequently Asked Questions (FAQs), and project source code.
Some GNU/Linux systems come with Subversion available on the installation CDs. Thus, you may be able to install a pre-built binary for your system, or use a package manager to download and install it.
Subversion uses the "even/odd" release model. Even numbered point releases (1.0, 1.2, etc.) are considered to be stable releases. Such releases undergo change only to fix problems. New features are not added, and users can expect to use the software without problems. Odd numbered point releases (1.1, 1.3, etc.), on the other hand, are development versions. New features are added in such versions, they tend to undergo rapid change and evolution, and such releases may have bugs or problems that could cause loss of data. You should use an even-numbered release if stability and data preservation are important to you. Use an odd-numbered release only if it has a critical, must-have feature and if you are willing to live with the risks involved.
The one constant in the Open Source world is change. At the time of writing, Subversion 1.0 is the current released stable version. The first development release of Subversion 1.1 is also available. Along with a host of fixes and several new command-line options, the next version has the following interesting features:
Symbolic links may be versioned
Unix-style symbolic links are stored in the repository as a regular file with a special attribute. The svn client knows how to store and extract symbolic links correctly on Unix-style systems.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using Subversion: A Quick Tour
Inhaltsvorschau
This section provides a very quick tour of using Subversion for version control. We start with the initial version of a project for importing into Subversion:

    $ find /tmp/hello -print                  

               Show directory layout

    /tmp/hello

    /tmp/hello/branches                       Directory for branch development

    /tmp/hello/tags                           Directory for tagged releases

    /tmp/hello/trunk

    /tmp/hello/trunk/hello.c                  Mainline development is done on the trunk

    /tmp/hello/trunk/Makefile

    /tmp/hello/trunk/README
The next steps are to create the repository and then to import the project into it:

    $ svnadmin create /path/to/svnrepos

    $ svn import /tmp/hello file:///path/to/svnrepos -m "initial import"

    Adding         /tmp/hello/trunk

    Adding         /tmp/hello/trunk/hello.c

    Adding         /tmp/hello/trunk/Makefile

    Adding         /tmp/hello/trunk/README

    Adding         /tmp/hello/branches

    Adding         /tmp/hello/tags



    Committed revision 1.
Now that the project exists in Subversion, we check out a working copy into a sandbox underneath our home directory and start making changes:

    $ cd                                           

               Move to home directory

    $ svn checkout file:///path/to/svnrepos hello  

               Check out working copy

    A  hello/trunk

    A  hello/trunk/hello.c

    A  hello/trunk/README

    A  hello/trunk/Makefile

    A  hello/branches

    A  hello/tags

    Checked out revision 1.



    $ cd hello/trunk                               

               Change to sandbox

    $ vi message.c hello.c Makefile                

               Make changes

    3 files to edit



    $ cat message.c                                

               Show newly created file

    const char message[  ] = "hello, world!";

    $ make                                         

               Compile program and test it

    cc    -c -o hello.o hello.c

    cc    -c -o message.o message.c

    cc -O hello.o message.o -o hello

    $ 
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The Subversion Command Line Client: svn
Inhaltsvorschau
The syntax for the Subversion command line client, svn, is:

    svn [options

                

                

] subcommand [arguments]

The options and subcommand may be provided in any order.
While Subversion has different options for its subcommands, all options are global—that is, each option is guaranteed to mean the same thing regardless of the subcommand that you use it with. For example, --verbose (-v) always means "verbose output," no matter which subcommand you use it with.
--auto-props
Enable auto-props, overriding the enable-auto-props directive in the config file.
--config-dir dir
Read configuration information from the specified directory instead of the default location (.subversion in the user's home directory).
--diff-cmd cmd
Use cmd as the external program to show differences between files. Normally, svn diff uses Subversion's internal diff engine, which provides unified diffs by default. To use an external diff program, use --diff-cmd. You can pass options to the diff program with the --extensions option (discussed later in this list).
--diff3-cmd cmd
Use cmd as the external program to merge files.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Repository Administration: svnadmin
Inhaltsvorschau
svnadmin is the administrative tool for monitoring and repairing your Subversion repository.
--bdb-log-keep
Disable automatic log removal of database log files. (Berkeley DB-specific)
--bdb-txn-nosync
Disable use of fsync() when committing database transactions. (Berkeley DB-specific)
--bypass-hooks
Bypass the repository hook system.
--clean-logs
Remove unused Berkeley DB logs.
--force-uuid
By default, when loading data into a repository that already contains revisions, svnadmin ignores the UUID from the dump stream. This option causes the repository's UUID to be set to the UUID from the stream.
--ignore-uuid
By default, when loading an empty repository, svnadmin uses the UUID from the dump stream. This option causes that UUID to be ignored.
--incremental
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Examining the Repository: svnlook
Inhaltsvorschau
svnlook is a command-line utility for examining different aspects of a Subversion repository. It does not make any changes to the repository. svnlook is typically used by the repository hooks, but a repository administrator might find it useful for diagnostic purposes.
Since svnlook works via direct repository access (and thus can only be used on the machine that holds the repository), it refers to the repository with a path, not a URL.
If no revision or transaction is specified, svnlook defaults to the youngest (most recent) revision of the repository.
Options in svnlook are global, just like in svn and svnadmin; however, most options only apply to one subcommand since the functionality of svnlook is (intentionally) limited in scope.
--no-diff-deleted
Do not print differences for deleted files. The default behavior when a file is deleted in a transaction/revision is to print the same differences that you would see if you had left the file but removed all the content.
--revision rev, -r rev
Examine revision number rev.
--show-ids
Show the filesystem node revision IDs for each path in the filesystem tree.
--transaction tid, -t
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Providing Remote Access: svnserve
Inhaltsvorschau
svnserve provides access to Subversion repositories using the svn network protocol. You can run svnserve either as a standalone server process, or you can have another process, such as inetd, xinetd, or sshd, start it for you.
Once the client has selected a repository by transmitting its URL, svnserve reads a file named conf/svnserve.conf in the repository directory to determine repository-specific settings such as what authentication database to use and what authorization policies to apply. The details are provided in Version Control with Subversion.
Unlike the previous commands we've described, svnserve has no subcommands--svnserve is controlled exclusively by options.
--daemon, -d
Run in daemon mode. svnserve backgrounds itself and accepts and serves TCP/IP connections on the svn port (3690, by default).
--foreground
When used together with -d, this option causes svnserve to stay in the foreground. This option is mainly useful for debugging.
--help, -h
Display a usage summary and exit.
--inetd, -i
Use the standard input/standard output file descriptors, as is appropriate for a server running out of inetd.
--listen-host
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Other Subversion Components
Inhaltsvorschau
Subversion creates the mod_dav_svn plug-in for use with the Apache 2.0 httpd web server. By running Apache 2.0 with mod_dav_svn, you can make your repository available via the HTTP protocol. Full details are provided in Version Control with Subversion, which is cited in the Bibliography. Two other commands are supplied with Subversion.
svndumpfilter

svndumpfilter subcommand [options] paths ...
Filter out files from a repository dump for use in later repository restoration (see svnadmin dump and svnadmin load).
Subcommands
exclude
Exclude from the dump the files and directories named by paths. Everything else is left in the dump.
help, h, ?
Print a help message and exit.
include
Include in the dump only the files and directories named by paths. Everything else is excluded.
Options
--drop-empty-revs
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 16: The GNU make Utility
Inhaltsvorschau
The make program is a long time mainstay of the Unix toolset. It automates the building of software and documentation based on a specification of dependencies among files; e.g., object files that depend upon program source files, or PDF files that depend upon documentation program input files. GNU make is the standard version for GNU/Linux and Mac OS X.
This chapter presents the following topics:
  • Conceptual overview
  • Command-line syntax
  • Makefile lines
  • Macros
  • Special target names
  • Writing command lines
For more information, see Managing Projects with GNU make and GNU Make: A Program for Directing Recompilation, both listed in the Bibliography.
The software download site for GNU make is ftp://ftp.gnu.org/gnu/make/.
The make program generates a sequence of commands for execution by the Unix shell. It uses a table of file dependencies provided by the programmer, and with this information, can perform updating tasks automatically for the user. It can keep track of the sequence of commands that create certain files, and the list of files or programs that require other files to be current before they can be rebuilt correctly. When a program is changed, make can create the proper files with a minimum of effort.
Each statement of a dependency is called a rule. Rules define one or more targets, which are the files to be generated, and the files they depend upon, the prerequisites or dependencies. For example, prog.o would be a target that depends upon prog.c; each time you update prog.c, prog.o must be regenerated. It is this task that make automates, and it is a critical one for large programs that have many pieces.
The file containing all the rules is termed a makefile
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
The make program generates a sequence of commands for execution by the Unix shell. It uses a table of file dependencies provided by the programmer, and with this information, can perform updating tasks automatically for the user. It can keep track of the sequence of commands that create certain files, and the list of files or programs that require other files to be current before they can be rebuilt correctly. When a program is changed, make can create the proper files with a minimum of effort.
Each statement of a dependency is called a rule. Rules define one or more targets, which are the files to be generated, and the files they depend upon, the prerequisites or dependencies. For example, prog.o would be a target that depends upon prog.c; each time you update prog.c, prog.o must be regenerated. It is this task that make automates, and it is a critical one for large programs that have many pieces.
The file containing all the rules is termed a makefile; for GNU make, it may be named GNUmakefile, makefile or Makefile, in which case make will read it automatically, or you may use a file with a different name and tell make about it with the -f option.
Over the years, different enhancements to make have been made by many vendors, often in incompatible ways. POSIX standardizes how make is supposed to work. Today, GNU make is the most popular version in the Unix world. It has (or can emulate) the features of just about every other version of make, and many Open Source programs require it.
This chapter covers GNU make. Commercial Unix systems come with versions derived from the original System V version; these can be used for bootstrapping GNU make if need be. On the x86 versions of Solaris 10, you can find GNU make in /usr/sfw/bin/gmake. It isn't available on the Sparc version, although it can be easily bootstrapped with the standard version of make in /usr/ccs/bin.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
The make program is invoked as follows:

    make  [options

                

]  [targets]  [macro definitions]
Options, targets, and macro definitions can appear in any order. The last assignment to a variable is the one that's used. Macro definitions are typed as:

               name=string

            
or

               name:=string

            
For more information, see the section "Creating and Using Macros," later in this chapter.
If no GNUmakefile, makefile, or Makefile exists, make attempts to extract the most recent version of one from either an RCS file, if one exists, or from an SCCS file, if one exists. Note though, that if a real makefile exists, make will not attempt to extract one from RCS or SCCS, even if the RCS or SCCS file is newer than the makefile.
Like just about every other GNU program, GNU make has both long and short options. The available options are as follows:
-b
Silently accepted, but ignored, for compatibility with other versions of make.
-B, --always-make
Treat all targets as out of date. All targets are remade, no matter what the actual status is of their prerequisites.
-C dir, --directory= dir
Change directory to dir before reading makefiles. With multiple options, each one is relative to the previous. This is usually used for recursive invocations of
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Makefile Lines
Inhaltsvorschau
Instructions in the makefile are interpreted as single lines. If an instruction must span more than one input line, use a backslash (\) at the end of the line so that the next line is considered a continuation. The makefile may contain any of the following types of lines:
Blank lines
Blank lines are ignored.
Comment lines
A number sign (#) can be used at the beginning of a line or anywhere in the middle. make ignores everything after the #.
Dependency lines
One or more target names, a single- or double-colon separator, and zero or more prerequisites:

                        targets : prerequisites

                        targets :: prerequisites

                     
In the first form, subsequent commands are executed if the prerequisites are newer than the target. The second form is a variant that lets you specify the same targets on more than one dependency line. (This second form is useful when the way you rebuild the target depends upon which prerequisite is newer.) In both forms, if no prerequisites are supplied, subsequent commands are always executed (whenever any of the targets are specified). For example, the following is invalid, since single-colon rules do not allow targets to repeated:

    # PROBLEM: Single colon rules disallow repeating targets

    whizprog.o: foo.h

            $(CC) -c $(CFLAGS) whizprog.o

            @echo built for foo.h



    whizprog.o: bar.h

            $(CC) -c $(CFLAGS) whizprog.o

            @echo built for bar.h

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Macros
Inhaltsvorschau
This section summarizes creating and using macros , internal macros, macro modifiers, macros with special handling, and text manipulation with macros and functions.
Macros (often called variables) are like variables in a programming language. In make, they are most similar to variables in the shell language, having string values that can be assigned, referenced, and compared.

Section 16.4.1.1: Defining macros

GNU make provides multiple ways to define macros. The different mechanisms affect how make treats the value being assigned. This in turn affects how the value is treated when the macro's value is retrieved, or referenced. GNU make defines two types of variables, called recursively expanded variables and simply expanded variables, respectively. The various macro assignment forms are as follows:
name = value
Create a recursively expanded variable. The value of name is the verbatim text on the right side of the =. If this value contains any references to other variable values, those values are retrieved and expanded when the original variable is referenced. For example:

    bar = v1

    foo = $(bar)            Value of bar retrieved when foo's value is referenced

    ...

    x = $(foo)              x is assigned 'v1'

    bar = v2

    y = $(foo)              y is assigned 'v2'

                           
name := value
Create a simply expanded variable. The value is expanded completely, immediately at the time of the assignment. Any variable references in
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Special Target Names
Inhaltsvorschau
.DEFAULT:
Commands associated with this target are executed if make can't find any makefile entries or suffix rules with which to build a requested target.
.DELETE_ON_ERROR:
If this target appears in a makefile, then for any target that make is rebuilding, if its command(s) exit with a nonzero status, make deletes the target.
.EXPORT_ALL_VARIABLES:
The mere existence of this target causes make to export all variables to child processes.
.IGNORE:
With prerequisites, ignore problems just for those files. For historical compatibility, with no prerequisites, ignore error returns from all commands. This is the same as the -i option.
.INTERMEDIATE:
Prerequisites for this target are treated as intermediate files, even if they are mentioned explicitly in other rules. (An intermediate file is one that needs to be built "along the way" to the real target. For example, making a .c file from a .y file, in order to create a .o object file. The .c file is an intermediate file.) This prevents them from being re-created, unless one of their prerequisites is out of date.
.LOW_RESOLUTION_TIME:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Writing Command Lines
Inhaltsvorschau
Writing good, portable makefile files is a bit of an art. Skill comes with practice and experience. Here are some tips to get you started:
  • Depending upon your locale, naming your file Makefile instead of makefile can cause it to be listed first with ls. This makes it easier to find in a directory with many files.
  • Remember that command lines must start with a leading tab character. You cannot just indent the line with spaces, even eight spaces. If you use spaces, make exits with an unhelpful message about a "missing separator."
  • Remember that $ is special to make. To get a literal $ into your command lines, use $$. This is particularly important if you want to access an environment variable that isn't a make macro. Also, if you wish to use the shell's $$ for the current process ID, you have to type it as $$$$.
  • Write multiline shell statements, such as shell conditionals and loops, with trailing semicolons and a trailing backslash:
    
        if [ -f specfile ] ; then \
    
        ... ; \
    
        else \
    
        ... ; \
    
        fi
    Note that the shell keywords then and else don't need the semicolon. (What happens is that make passes the backslashes and the newlines to the shell. The escaped newlines are not syntactically important, so the semicolons are needed to separate the different parts of the command. This can be confusing. If you use a semicolon where you would normally put a newline in a shell script, things should work correctly.)
  • Remember that each line is run in a separate shell. This means that commands that change the shell's environment (such as cd) are ineffective across multiple lines. The correct way to write such commands is to keep the commands on the same line, separated with a semicolon. In the particular case of
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 17: The GDB Debugger
Inhaltsvorschau
The GNU Debugger, GDB, is the standard debugger on GNU/Linux and BSD systems, and can be used on just about any Unix system with a C compiler and at least one of several well-known object file formats. It can be used on other kinds of systems as well. It has a very rich feature set, making it the preferred debugger of many developers the world over.
This chapter covers the following topics:
  • Conceptual overview
  • Command-line syntax
  • Initialization files
  • GDB expressions
  • The GDB text user interface
  • Group listing of GDB commands
  • Summary of set and show commands
  • Summary of info command
  • Alphabetical summary of GDB commands
For more information, see Debugging with GDB: The GNU Source-Level Debugger, listed in the Bibliography.
A debugger is a program that lets you run a second program, which we will call the debuggee. The debugger lets you examine and change the state of the debuggee, and control its execution. In particular, you can single-step the program, executing one statement or instruction at a time, in order to watch the program's behavior.
Debuggers come in two flavors: instruction-level debuggers , which work at the level of machine instructions, and source-level debuggers , which operate in terms of your program's source code and programming language. The latter are considerably easier to use, and usually can do machine-level debugging if necessary. GDB is a source level debugger; it is probably the most widely applicable debugger (portable to the largest number of architectures) of any current debugger.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Conceptual Overview
Inhaltsvorschau
A debugger is a program that lets you run a second program, which we will call the debuggee. The debugger lets you examine and change the state of the debuggee, and control its execution. In particular, you can single-step the program, executing one statement or instruction at a time, in order to watch the program's behavior.
Debuggers come in two flavors: instruction-level debuggers , which work at the level of machine instructions, and source-level debuggers , which operate in terms of your program's source code and programming language. The latter are considerably easier to use, and usually can do machine-level debugging if necessary. GDB is a source level debugger; it is probably the most widely applicable debugger (portable to the largest number of architectures) of any current debugger.
GDB itself provides two user interfaces : the traditional command-line interface (CLI) and a text user interface (TUI). The latter is meant for regular terminals or terminal emulators, dividing the screen into separate "windows" for the display of source code, register values, and so on.
GDB provides support for debugging programs written in C, C++, Objective C, Java, and Fortran. It provides partial support for Modula-2 programs compiled with the GNU Modula-2 compiler and for Ada programs compiled with the GNU Ada Translator, GNAT. GDB provides some minimal support for debugging Pascal programs. The Chill language is no longer supported.
When working with C++ and Objective C, GDB provides name demangling . C++ and Objective C encode overloaded procedure names into a unique "mangled" name that represents the procedure's return type, argument types, and class membership. This ensures so-called type-safe linkage . There are different methods for name mangling, thus GDB allows you to select among a set of supported methods, besides just automatically demangling names in displays.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Command-Line Syntax
Inhaltsvorschau
GDB is invoked as follows:

    gdb [options] [executable [corefile-or-PID]]

    gdb [options] --args executable [program args ...]
The gdbtui command is equivalent to gdb --tui; it invokes GDB with the Text User Interface. The TUI is described in the later section "The GDB Text User Interface."
GDB has both traditional short options and GNU-style long options. Long options may start with either one or two hyphens. The command-line options are as follows.
--args
Pass on arguments after executable to the program being debugged.
--async, --noasync
Enable/disable the asynchronous version of the command-line interface.
-b baudrate, --baud baudrate
Set the serial port baud rate used for remote debugging.
--batch
Process options and then exit.
--cd dir
Change current directory to dir.
-c file, --core file
Analyze the core dump file.
-d dir, --directory dir
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Initialization Files
Inhaltsvorschau
Two files are used to initialize GDB and the readline library, respectively.
At startup, GDB reads its initialization file. This is a file of commands, such as option settings, that you tell GDB to run every time it starts up. The initialization file is named .gdbinit on Unix (BSD, Linux, etc.) systems. Some MS-Windows versions of GDB use gdb.ini instead. Empty lines (they do nothing) are allowed, and comments in initialization files start with a # and continue to the end of the line. GDB executes commands from initialization files and from the command line in the following order:
  1. Commands in $HOME/.gdbinit. This acts as a "global" initialization; settings that should always be used go here.
  2. Command-line options and operands.
  3. Commands in ./.gdbinit. This allows for option settings that apply to a particular program by keeping the file in the same directory as the program's source code.
  4. Command files specified with the -x option.
You may use the -nx option to make GDB skip the execution of the initialization files.
Just like the Bash shell (see Chapter 4), GDB uses the readline library to provide command-line history and editing. You may use either vi- or Emacs-style commands for editing your command line. The readline library reads the file ~/.inputrc to initialize its settings and options. The details are beyond the scope of this book; see the Bash and GDB documentation or the online Info system for the full story. Here is a sample .inputrc file:

    set editing-mode vi                Use vi editor commands

    set horizontal-scroll-mode On      Scroll line left/right as cursor moves along it
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
GDB Expressions
Inhaltsvorschau
GDB can be thought of as a specialized programming language. It has variables and operators similar to those of C, and special features for debugging. This section looks at the different kinds of expressions that GDB understands.
Every time you print a value with print, GDB saves the value in the value history . You can reference these saved values by their numeric place in the history, preceded with a $. GDB reminds you of this by printing $ n = val. For example:

    $ gdb whizprog

    ...

    (gdb) print stopped_early

    $1 = 0

    (gdb) print whiny_users

    $2 = TRUE

    (gdb)
A plain $ refers to the most recent value in the value history. This can save considerable typing. If you've just looked at a pointer variable, you can use:

    (gdb) print *$

               
to print the contents of whatever the pointer is pointing to. $$ refers to the next most recent value in the history, and $$ n refers to the value n places from the end. (Thus, $ n counts from the beginning, while $$ n counts from the end.)
You can use show values to see the values in the history. Whenever GDB reloads the executable (rereads the symbol table), it clears the value history. This is because the value history may have contained pointers into the symbol table and such pointers become invalid when the symbol table is reloaded.
GDB lets you create convenience variables . These are variables you can use to store values as you need them. Their names begin with a $ and consist of alphanumeric characters and underscores. They should start with a letter or underscore. (Note that values in the value history have names that are numeric.) You might want to use a convenience variable as an array index:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The GDB Text User Interface
Inhaltsvorschau
GDB , in its default mode, shows its line-oriented heritage. When single stepping, it displays only one line of source code at a time. Graphical debuggers can show you much more, and indeed many programmers prefer a graphical debugger, if only for this reason. However, recent versions of GDB offer a Text User Interface (TUI), which uses the tried-and-true curses library to provide several "windows" on a regular terminal or terminal emulator, such as an xterm. This can be quite effective, especially since it allows you to do everything from the keyboard.
A number of set options and GDB commands are specific to the TUI. These are listed along with the rest of the set options and GDB commands in the later sections "Summary of set and show Commands" and "Alphabetical Summary of GDB Commands."
Unfortunately (as of GDB 6.3), the TUI is still immature; the author could not get several documented features to work. Thus this book doesn't provide detailed coverage of it. However, it should improve over time, and you should continue to evaluate it to see if it meets your needs.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Group Listing of GDB Commands
Inhaltsvorschau
This section summarizes the GDB commands by task. Esoteric commands, such as those used by GDB's maintainers, or to cross-debug remote systems connected via serial port or a network, have been omitted.
Alias
Short for...
Alias
Short for...
Alias
Short for...
bt
backtrace
f
frame
p
print
c
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary of set and show Commands
Inhaltsvorschau
The set command accepts a large number of different parameters that control GDB's behavior. Many of the accepted parameters are rather esoteric. The show command displays the values of the same parameters as set accepts. This section summarizes the parameters and how they affect GDB.
For most of the options, set option and set option on are equivalent; they enable the option. Use set option off to disable the option.
annotate

set annotate level

show annotate
Set the annotation_level variable to level. GUI programs that call GDB as a subsidiary process use this variable.
architecture

set architecture architecture

show architecture
Set the architecture of target to architecture. Primarily used in cross-debugging.
args

set args

show args
Give the debuggee the argument list when you start it. The run command uses this list when it isn't given any arguments. See the entry for run in the later section "Alphabetical Summary of GDB Commands."
auto-solib-add

set auto-solib-add

show auto-solib-add
Automatically load symbols from shared libraries as needed. When set to off, symbols must be loaded manually with the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary of the info Command
Inhaltsvorschau
The info command displays information about the state of the debuggee (as opposed to show, which provides information about internal GDB features, variables and options). With no arguments, it provides a list of possible features about which information is available.
info ...
Information displayed
address sym
Information about where symbol sym is stored. This is either a memory address or a register name.
all-registers
Information about all registers, including floating-point registers.
args
Information about the arguments to the current function (stack frame).
break [bpnum]
Information about breakpoint bpnum if given, or about all breakpoints if not.
breakpoints [bpnum]
Same information as the info break command.
catch
Information on exception handlers active in the current frame.
classes [regexp]
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of GDB Commands
Inhaltsvorschau
The following alphabetical summary of GDB commands includes all those that are useful for day-to-day debugging. Esoteric commands, such as those used by GDB's maintainers, or to cross-debug remote systems connected via serial port or a network, have been omitted.
Many of these commands may be abbreviated. The list of abbreviations is provided in the earlier section "Aliases for Other Commands."
add-symbol-file

add-symbol-file file addr [-readnow]

add-symbol-file file [-s section address ...]
Read additional symbol table information from file, which was dynamically loaded into the debuggee outside of GDB's knowledge. You must tell GDB the address at which it was loaded, since GDB cannot determine this on its own. The -readnow option is the same as for the file command; see file for more information. You may use -s to name the memory starting at address with the name section. You can provide multiple section/address pairs with multiple
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 18: Writing Manual Pages
Inhaltsvorschau
The man command prints the online "manual page" for commands, system calls, functions, devices and file formats. Developers creating new software also need to create manual pages for their programs. This in turn requires a basic understanding of the Unix troff text-processing program and the man macro package.
This chapter presents the following topics:
  • Introduction
  • Overview of nroff/troff
  • Alphabetical summary of the man macros
  • Predefined strings
  • Names used internally by the man macros
  • Sample document
The standard Unix text-processing tools are nroff and troff. They are not What You See Is What You Get (WYSIWYG) word-processors. Rather, they are text processing programs, where the input consists of a mixture of text to be formatted and special commands that instruct the programs how to format the text.
troff is for output devices such as typesetters and high resolution laser printers that can handle variable-width fonts and different character sizes. nroff is for simpler devices where all characters have the same width, such as terminals or line printers. Both programs accept the same set of commands; thus, carefully prepared input may be used with both programs to produce reasonable results. The original troff program worked for only one specific typesetter. The modern version, known as "device independent troff," or ditroff, can be tuned via specific drivers to work on multiple output devices.
Different commercial versions of Unix come with different versions of the troff suite. GNU/Linux and BSD systems all use GNU troff (groff), which is an excellent, full-featured implementation of ditroff and all the troff preprocessors. The Internet starting point for
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Introduction
Inhaltsvorschau
The standard Unix text-processing tools are nroff and troff. They are not What You See Is What You Get (WYSIWYG) word-processors. Rather, they are text processing programs, where the input consists of a mixture of text to be formatted and special commands that instruct the programs how to format the text.
troff is for output devices such as typesetters and high resolution laser printers that can handle variable-width fonts and different character sizes. nroff is for simpler devices where all characters have the same width, such as terminals or line printers. Both programs accept the same set of commands; thus, carefully prepared input may be used with both programs to produce reasonable results. The original troff program worked for only one specific typesetter. The modern version, known as "device independent troff," or ditroff, can be tuned via specific drivers to work on multiple output devices.
Different commercial versions of Unix come with different versions of the troff suite. GNU/Linux and BSD systems all use GNU troff (groff), which is an excellent, full-featured implementation of ditroff and all the troff preprocessors. The Internet starting point for groff is http://www.gnu.org/software/groff/groff.html. We recommend downloading and building it if you intend to do serious troff-based typesetting work.
Knowledge of nroff and troff was once an integral part of a Unix wizard's claims to Unix mastery. Over time though, they have been superseded for daily document preparation, either by WYSIWYG programs, or by TEX and LATEX. More information about troff in general is available from http://www.troff.org/.
However, one important task where knowledge of troff is still handy is the writing of manual pages (for the man command) to accompany software. This chapter introduces the subset of the troff command and feature set that is useful for writing manual pages, and then describes the man macros, concluding with a sample manual page. See also the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Overview of nroff/troff
Inhaltsvorschau
This section is condensed from the material on troff from the third edition of this book. It covers features available in all versions of nroff and troff, and focuses on those features necessary for writing manual pages.
nroff and troff are invoked from the command line as follows:

    nroff  [options]  [files]

    troff  [options]  [files]
Although both formatters support a plethora of options, the following two are the most important for everyday use.
-m name
Prepend a macro file to input files. Historically, one of /usr/lib/tmac/tmac. name or /usr/share/lib/tmac/tmac. name were the locations of the macros for name. Solaris uses /usr/share/lib/tmac/ name. GNU troff uses something like /usr/local/share/groff/ x.y.z /tmac/ name .tmac. The actual location and filename(s) vary among different Unix systems.
-T name
Prepare output designed for printer or typesetter name. For device names, see your specific documentation or a local expert. GNU troff provides both PostScript and TEX DVI output.

Section 18.2.1.1: Example

Format a manual page for printing using groff
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Alphabetical Summary of man Macros
Inhaltsvorschau
Brian Kernighan describes the reason for macro packages very pithily:
Since bare troff is unusable by humans, a race of gods now gone created macro packages for mortals to use.
Today, the man macros are the most widely used macro package. They are used for writing program manual pages for the online manual, accessed via the man command.
As many as six arguments may be given for all the macros that change fonts or produce a heading. The seventh and later arguments are ignored. Use double quotes around multiple words to get longer headings.
The .TS, .TE, .EQ, and .EN macros are not defined by the man macros. Because nroff and troff ignore unknown requests, you can still use them in your manpages; tbl and eqn work with no problems.
.B

.B [text ...]
Set the arguments in the bold font, with a space between each argument. If no arguments are supplied, the next input line is set in bold.
.BI

.BI barg iarg ...
Set alternating barg in bold and iarg in italic, with no intervening spaces.
.BR

.BR barg rarg ...
Set alternating barg in bold and rarg in roman, with no intervening spaces.
.DT

.DT
Reset the tab stops to their defaults, every 1/2 inch.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Predefined Strings
Inhaltsvorschau
The following strings are predefined by the man macros; of these, only R and S are documented.
String
Effect in troff
Effect in nroff
\*(lq
'' ('')
"
\*(rq
'' ('')
"
\*R
\(rg (®)
(Reg.)
\*S
Restore default point size
Restore default point size
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Internal Names
Inhaltsvorschau
The Solaris man macros use a number of macro, string, and number register names that begin with ], }, and ). Such names should be avoided in your own files.
The number registers D, IN, LL, P, X, d, m, and x are used internally by the Solaris man macros. Using .nr D 1 before calling the .TH macro generates pages with different even and odd footers.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Sample Document
Inhaltsvorschau
The output of this sample document is shown in Figure 18-1.

    .TH WHIZPROG 1 "April 1, 2007"

    .SH NAME

    whizprog \- do amazing things

    .SH SYNOPSIS

    .B whizprog

    [

    .I options

    ] [

    .I files

    \&... ]

    .SH DESCRIPTION

    .I Whizprog

    is the next generation of really

    .B cool

    do-it-all programs. ...

    .SH OPTIONS

    .PP

    .I Whizprog

    accepts the following options.

    .TP \w'\fB\-\^\-level\fP'u+3n

    .PD 0

    .B \-h

    .TP

    .PD

    .B \-\^\-help

    Print a helpful message and exit.

    .TP

    .BI \-\^\-level " level"

    Set the level for the

    .B \-\^\-stun

    option.

    .TP

    .B \-\^\-stun

    Stun the competition, or other beings, as needed. ...

    .SH SEE ALSO

    .IR "Whizprog \- The Be All and End All Program" ,

    by J. Programmer.

    .PP

    .IR wimpprog (1)

    .SH FILES

    .B /dev/phaser

    .br

    .B /dev/telepath

    .SH CAVEATS

    .PP

    There are a number of important points to remember.

    .RS

    .IP 1.

    Use

    .B \-\^\-help

    to get help.

    .IP 2.

    Use

    .B \-\^\-stun

    with care.  ...

    .RE

    Forget these at your own risk!

    .SH BUGS

    The

    .B \-\^\-stun

    option currently always uses

    .BR "\-\^\-level 10" ,

    making it rather dangerous.

    .SH AUTHOR

    J. Programmer,

    .B jp@wizard-corp.com
Figure 18-1: Output of sample document
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Appendix A: ISO 8859-1 (Latin-1) Character Set
Inhaltsvorschau
This appendix presents the set of ISO 8859-1 (Latin-1) characters, along with their equivalent values in decimal, octal, and hexadecimal. This character set suffices for English and languages that can be written using just the English alphabet, plus the major Western European languages. The lower half of this set of characters is identical to traditional ASCII . Table A-1 shows nonprinting characters; it's useful when you need to represent nonprinting characters in some printed form, such as octal. For example, the echo and tr commands let you specify characters using octal values of the form \nnn. Also, the od command can display nonprinting characters in a variety of forms.
Table A-2 shows printing characters. This table is useful when using the previous commands, but also when specifying a range of characters in a pattern-matching construct. The characters from decimal 128–159 are not used in Latin-1.
Table A-1: Nonprinting characters
Decimal
Octal
Hex
Character
Remark
0
000
00
CTRL-@
NUL (Null prompt)
1
001
01
CTRL-A
SOH (Start of heading)
2
002
02
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Appendix B: Bibliography
Inhaltsvorschau
Many books have been written about Unix and related topics. It would be impossible to list them all, nor would that be very helpful. In this chapter, we present the "classics"--those books that the true Unix wizard has on his or her shelf. (Alas, some of these are now out of print; thus only older Unix wizards have them.)
Because Unix has affected many aspects of computing, you will find books listed here on things besides just the Unix operating system itself.
This chapter presents:
  • Unix descriptions and programmer's manuals
  • Unix internals
  • System and network administration
  • Programming with the Unix mindset
  • Programming languages
  • TCP/IP networking
  • Software development
  • Emacs
  • Standards
  • O'Reilly books

Unix Descriptions and Programmer's Manuals

Unix Internals

System and Network Administration

Programming with the Unix Mindset

Programming Languages

TCP/IP Networking

Software Development

Emacs

Standards

O'Reilly Books

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Unix Descriptions and Programmer's Manuals
Inhaltsvorschau
  1. The Bell System Technical Journal, Volume 57 Number 6, Part 2, July-August 1978. AT&T Bell Laboratories, Murray Hill, NJ, USA. ISSN 0005-8580. A special issue devoted to Unix, by the creators of the system.
  2. AT&T Bell Laboratories Technical Journal, Volume 63 Number 8, Part 2, October 1984. AT&T Bell Laboratories, Murray Hill, NJ, USA. Another special issue devoted to Unix.
    These two volumes were republished as:
  3. UNIX System Readings and Applications, Volume 1, Prentice Hall, Englewood Cliffs, NJ, USA, 1987. ISBN 0-13-938532-0.
  4. UNIX System Readings and Applications, Volume 2, Prentice Hall, Englewood Cliffs, NJ, USA, 1987. ISBN 0-13-939845-7.
  5. UNIX Time-sharing System: UNIX Programmers Manual, Seventh Edition, Volumes 1, 2A, 2B. Bell Telephone Laboratories, Inc., January 1979.
    These are the reference manuals (Volume 1), and descriptive papers (Volumes 2A and 2B) for the landmark Seventh Edition Unix system, the direct ancestor of all current commercial Unix systems.
    They were reprinted by Holt Rinehart & Winston, but are now long out of print. However, they are available online from Bell Labs in troff source, PDF, and PostScript formats. See http://plan9.bell-labs.com/7thEdMan.
  6. UNIX Research System: Programmer's Manual, Tenth Edition, Volume 1, AT&T Bell Laboratories, M.D. McIlroy and A.G. Hume editors, Holt Rinehart & Winston, New York, NY, USA, 1990. ISBN 0-03-047532-5.
  7. UNIX Research System: Papers, Tenth Edition, Volume 2, AT&T Bell Laboratories, M.D. McIlroy and A.G. Hume editors, Holt Rinehart & Winston, New York, NY, USA, 1990. ISBN 0-03-047529-5.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Unix Internals
Inhaltsvorschau
The dedicated Unix wizard knows not only how to use his or her system, but how it works.
  1. Lions' Commentary on UNIX 6th Edition, with Source Code, John Lions. Peer-To-Peer Communications LLC, Charlottesville, VA, USA, 2005. ISBN 1-57398-013-7. http://www.peerllc.com/.
    This classic work provides the source code for the Sixth Edition Unix kernel, with a complete exegesis of it. It set the standard for clear exposition of operating system internals.
  2. The Design of the UNIX Operating System, Maurice J. Bach. Prentice Hall, Englewood Cliffs, NJ, USA, 1986. ISBN 0-13-201799-7.
    This book very lucidly describes the design of System V Release 2, with some discussion of important features in System V Release 3, such as STREAMS and the filesystem switch.
  3. The Magic Garden Explained: The Internals of Unix System V Release 4: An Open Systems Design, Berny Goodheart, James Cox, and John R. Mashey. Prentice Hall, Englewood Cliffs, NJ, USA, 1994. ISBN 0-13-098138-9.
  4. Unix Internals: The New Frontiers, Uresh Vahalia. Prentice Hall, Englewood Cliffs, NJ, USA, 1996. ISBN 0-13-101908-2.
  5. Solaris Internals: Core Kernel Architecture, Jim Mauro and Richard McDougall. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2000. ISBN 0-13-022496-0.
  6. UNIX(R) Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers, Curt Schimmel. Addison-Wesley, Reading, MA, USA, 1994. ISBN 0-201-63338-8.
  7. The Design and Implementation of the 4.3BSD UNIX Operating System, Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels and John S. Quarterman. Addison-Wesley, Reading, MA, USA, 1989. ISBN 0-201-06196-1.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
System and Network Administration
Inhaltsvorschau
Unix system administration is a complicated topic in its own right. In these days of single-user workstations, even regular users also have to understand basic system administration tasks. Besides managing the system (users, filesystems, accounting), administrators also have to understand TCP/IP network administration.
  1. UNIX System Administration Handbook, Third Edition, Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2000. ISBN 0-13-020601-6.
  2. Linux Administration Handbook, Evi Nemeth, Garth Snyder, and Trent R. Hein. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. ISBN 0-13-008466-2.
    A revision of the previous book focused on GNU/Linux.
  3. Essential System Administration, Third Edition, Æleen Frisch. O'Reilly Media, Inc., Sebastopol, CA, USA, 2002. ISBN 0-596-00343-9.
  4. DNS and BIND, Fouth Edition, Paul Albitz and Cricket Liu. O'Reilly Media, Inc., Sebastopol, CA, USA, 2001. ISBN 0-596-00158-4.
  5. TCP/IP Network Administration, Third Edition, Craig Hunt. O'Reilly Media, Inc., Sebastopol, CA, USA, 2002. ISBN 0-596-00297-1.
  6. Linux Network Administrator's Guide, Third Edition, Tony Bautts, Terry Dawson, and Gregor N. Purdy. O'Reilly Media, Inc. Sebastopol, CA, USA, 2005. ISBN 0-596-00548-2.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Programming with the Unix Mindset
Inhaltsvorschau
Any book written by Brian Kernighan deserves careful reading, usually several times. The first two books present the Unix "toolbox" programming methodology. They will help you learn how to "think Unix." The third book continues the process, with a more explicit Unix focus. The fourth and fifth are about programming in general, and also very worthwhile.
  1. Software Tools, Brian W. Kernighan and P. J. Plauger. Addison-Wesley, Reading, MA, USA, 1976. ISBN 0-201-03669-X.
    A wonderful book that presents the design and code for programs equivalent to Unix's grep, sort, ed, and others. The programs use RATFOR (Rational FORTRAN), a preprocessor for FORTRAN with C-like control structures.
  2. Software Tools in Pascal, Brian W. Kernighan and P. J. Plauger. Addison-Wesley, Reading, MA, USA, 1981. ISBN 0-201-10342-7.
    A translation of the previous book into Pascal. Still worth reading; Pascal provides many things that FORTRAN does not.
  3. The Unix Programming Environment, Brian W. Kernighan and Rob Pike. Prentice Hall, Englewood Cliffs, NJ, USA, 1984. ISBN 0-13-937699-2 (hardcover), 0-13-937681-X (paperback).
    This books focuses explicitly on Unix, using the tools in that environment. In particular, it adds important material on the shell, awk, and the use of lex and yacc. See http://cm.bell-labs.com/cm/cs/upe.
  4. The Elements of Programming Style, Second Edition, Brian W. Kernighan and P. J. Plauger. McGraw-Hill, New York, NY, USA, 1978. ISBN 0-07-034207-5.
    Modeled after Strunk & White's famous The Elements of Style, this book describes good programming practices that can be used in any environment.
  5. The Practice of Programming, Brian W. Kernighan and Rob Pike. Addison Wesley Longman, Reading, MA, USA, 1999. ISBN 0-201-61586-X.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Programming Languages
Inhaltsvorschau
A number of important programming languages were first developed under Unix. Note again the books written by Brian Kernighan.
  1. The C Programming Language, Brian W. Kernighan and Dennis M. Ritchie. Prentice Hall, Englewood Cliffs, NJ, USA, 1978. ISBN 0-13-110163-3.
    The original "bible" on C. Dennis Ritchie invented C and is one of the two "fathers" of Unix. This edition is out of print.
  2. The C Programming Language, Second Edition, Brian W. Kernighan and Dennis M. Ritchie. Prentice Hall, Englewood Cliffs, NJ, USA, 1988. ISBN 0-13-110362-8.
    This revision of the original covers the 1990 version of Standard C. It retains and improves upon the high qualities of the first edition. See http://cm.bell-labs.com/cm/cs/cbook.
  3. C: A Reference Manual, Fifth Edition, Samuel P. Harbison III and Guy L. Steele. Prentice Hall, Upper Saddle River, NJ, USA, 2002. ISBN 0-13-089592-X.
    An excellent discussion of the details for those who need to know. This edition covers everything from the original, pre-Standard C, through the 1999 version of Standard C.
  4. The C++ Programming Language, Special Third Edition, Bjarne Stroustrup. Addison-Wesley, Reading, MA, USA, 2000. ISBN 0-201-70073-5.
    The definitive statement on C++ by the language's inventor and the ANSI C++ committee chair. See http://www.awl.com/cseng/titles/0-201-70073-5/.
  5. The C++ Standard Library—A Tutorial and Reference, Nicolai M. Josuttis. Addison-Wesley, Reading, MA, USA, 1999. ISBN 0-201-37926-0.
  6. C++ Primer, Third Edition, Stanley B. Lippman and Josée Lajoie. Addison Wesley Longman, Reading, MA, USA, 1998. ISBN 0-201-82470-1.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
TCP/IP Networking
Inhaltsvorschau
The books by Comer are well-written; they are the standard descriptions of the TCP/IP protocols. The books by Stevens are also very highly regarded.
  1. Internetworking with TCP/IP Volume 1: Principles, Protocols, and Architecture, Fourth Edition, Douglas E. Comer. Prentice Hall, Upper Saddle River, NJ, USA, 2000. ISBN 0-13-018380-6.
  2. Internetworking With TCP/IP Volume 2: ANSI C Version: Design, Implementation, and Internals, Third Edition, Douglas E. Comer and David L. Stevens. Prentice Hall, Englewood Cliffs, NJ, USA, 1998. ISBN 0-13-973843-6.
  3. Internetworking With TCP/IP Volume 3: Client-Server Programming and Applications: Linux/Posix Sockets Version, Second Edition, Douglas E. Comer, David L. Stevens, Marshall T. Rose, and Michael Evangelista. Prentice-Hall, Englewood Cliffs, NJ, USA, 2000. ISBN 0-13-032071-4.
  4. TCP/IP Illustrated, Volume 1: The Protocols, W. Richard Stevens. Addison Wesley Longman, Reading, MA, USA, 1994. ISBN 0-201-63346-9.
  5. TCP/IP Illustrated, Volume 2: The Implementation, W. Richard Stevens and Gary R. Wright. Addison Wesley Longman, Reading, MA, USA, 1995. ISBN 0-201-63354-X.
  6. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the Unix Domain Protocols, W. Richard Stevens. Addison Wesley Longman, Reading, MA, USA, 1996. ISBN 0-201-63495-3.
  7. Unix Network Programming, Volume 1: The Sockets Networking API, Third Edition W. Richard Stevens, Bill Fenner and Andrew M. Rudoff. Addison-Wesley, Reading, MA, USA, 2003. ISBN 0-13-141155-1.
  8. Unix Network Programming, Volume 2: Interprocess Communications
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Software Development
Inhaltsvorschau
  1. Applying RCS and SCCS, Don Bolinger and Tan Bronson. O'Reilly Media, Inc., Sebastopol, CA, USA, 1995. ISBN 1-56592-117-8.
  2. Open Source Development with CVS, Third Edition, Karl Fogel and Moshe Bar. Paraglyph Press, Phoenix, AZ, USA, 2003. ISBN 1932111816.
    This book is available online: see http://cvsbook.red-bean.com/.
  3. Essential CVS, Jennifer Vesperman. O'Reilly Media, Inc., Sebastopol, CA, USA, 2003. ISBN 0-596-00459-1.
  4. Version Control With Subversion, Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. O'Reilly Media, Inc., Sebastopol, CA, USA, 2004. ISBN 0-596-00448-6.
  5. GNU Make: A Program for Directing Recompilation, Richard M. Stallman, Roland McGrath, and Paul D. Smith. The Free Software Foundation, Cambridge, MA, USA, 2004. ISBN 1-882114-83-3.
  6. Managing Projects with GNU make, Third Edition, Robert Mecklenburg, Andy Oram, and Steve Talbott. O'Reilly Media, Inc., Sebastopol, CA, USA, 2005. ISBN 0-596-00610-1.
  7. Debugging with GDB: The GNU Source-Level Debugger, Richard M. Stallman, Roland Pesch, Stan Shebs, et al. The Free Software Foundation, Cambridge, MA, USA, 2002. ISBN 1-882114-88-4.
  8. The Cathedral and the Bazaar, Eric S. Raymond, O'Reilly Media, Inc., Sebastopol, CA, USA, 2001. ISBN 0-596-00131-2 (hardback), 0-596-00108-8 (paperback).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Emacs
Inhaltsvorschau
  1. GNU Emacs Manual, for Version 21, Fifteenth Edition, Richard M. Stallman. The Free Software Foundation, Cambridge, MA, USA, 2002. ISBN 1-882114-85-X.
  2. An Introduction to Programming in Emacs Lisp, Revised Second Edition, Robert J. Chassell. The Free Software Foundation, Cambridge, MA, USA, 2004. ISBN 1-882114-56-6
  3. GNU Emacs Lisp Reference Manual (in two volumes), Bil Lewis, Dan LaLiberte, Richard Stallman, and the GNU Manual Group. The Free Software Foundation, Cambridge, MA, USA, 2000. ISBN 1-882114-73-6. Out of print.
  4. Learning GNU Emacs, Third Edition, Debra Cameron, James Elliott, and Marc Loy. O'Reilly Media, Inc., Sebastopol, CA, USA, 2005. ISBN 0-596-00648-9.
  5. Writing GNU Emacs Extensions, Bob Glickstein. O'Reilly Media, Inc., Sebastopol, CA, USA, 1997. ISBN 1-56592-261-1.
  6. GNU Emacs: UNIX Text Editing and Programming, Michael A. Schoonover, John S. Bowie, and William R. Arnold. Addison-Wesley, Reading, MA, USA, 1992. ISBN 0-201-56345-2.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Standards
Inhaltsvorschau
There are a number of "official" standards for the behavior of portable applications among Unix and Unix-like systems. The first entry is the current POSIX standard. The rest are the formal standards for the C and C++ programming languages.
  1. IEEE Standard 1003.1-2004: Standard for information Technology—Portable Operating System Interface (POSIX®). IEEE, New York, NY, USA, 2004.
    This is the POSIX standard. It combines both the system call interface standard and the shell and utilities standard in one document. The standard consists of several volumes: Base Definitions (Volume 1), System Interfaces (Volume 2), Shell and Utilities (Volume 3), and Rationale (Volume 4).
    The standard may be ordered from http://www.standards.ieee.org on CD-ROM (Product number SE95238, ISBN 0-7381-4049-X) or as PDF (Product number SS95238, ISBN 0-7381-4048-1).
  2. X3 Secretariat: Standard—The C Language. X3J11/90-013. ISO Standard ISO/IEC 9899. Computer and Business Equipment Manufacturers Association. Washington DC, USA, 1990.
  3. International Standard: Programming Languages—C. ISO Standard ISO/IEC 9899:1999(E). Information Technology Industry Council, Washington DC, USA, 1999.
    These two documents are the 1990 and 1999 standards for the C language. It generally takes five or more years from when a language standard is published until compilers for that version become widely available.
  4. X3 Secretariat: International Standard—The C++ Language. X3J16-14882. Information Technology Council (NSITC). Washington DC, USA, 1998.
    This is the initial standard for the C++ programming language, used by most C++ compilers as of this writing.
  5. International Standard: Programming Languages—C++. ISO Standard ISO/IEC 14882-2003. Information Technology Industry Council, Washington DC, USA, 2003.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
O'Reilly Books
Inhaltsvorschau
Here is a list of O'Reilly Media books cited throughout this book. There are, of course, many other O'Reilly books relating to Unix. See http://www.oreilly.com/catalog.
  1. Advanced Perl Programming, Second Edition, Simon Cozens. O'Reilly Media, Inc., Sebastopol, CA, USA, 2005. ISBN 0-596-00456-7
  2. Checking C Programs with lint, Ian F. Darwin. O'Reilly Media, Inc., Sebastopol, CA, USA, 1988. ISBN 0-937175-30-7.
  3. Classic Shell Scripting, Arnold Robbins and Nelson H.F. Beebe. O'Reilly Media, Inc., Sebastopol, CA, USA, 2005. ISBN 0-596-00595-4.
  4. Learning Perl, Third Edition, Randal L. Schwartz and Tom Phoenix. O'Reilly Media, Inc., Sebastopol, CA, USA, 2001. ISBN 0-596-00132-0.
  5. Learning the bash Shell, Third Edition, Cameron Newham and Bill Rosenblatt. O'Reilly Media, Inc., Sebastopol, CA, USA, 2005. ISBN 0-596-00965-8.
  6. Learning the Korn Shell, Second Edition, Bill Rosenblatt and Arnold Robbins. O'Reilly Media, Inc., Sebastopol, CA, USA, 2002. ISBN 0-596-00195-9.
  7. Learning Python, Second Edition, Mark Lutz and David Ascher. O'Reilly Media, Inc., Sebastopol, CA, USA, 2003. ISBN: 0-596-00281-5.
  8. Learning the Unix Operating System, Fifth Edition, Jerry Peek, Grace Todino, and John Strang. O'Reilly Media, Inc., Sebastopol, CA, USA, 2001. ISBN 0-596-00261-0.
  9. Learning the vi Editor, Sixth Edition, Linda Lamb and Arnold Robbins. O'Reilly Media, Inc., Sebastopol, CA, USA, 1998. ISBN 1-56592-426-6.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
	

Zurück zu Unix in a Nutshell


Themen

Buchreihen

Special Interest

International Sites

O'Reilly China O'Reilly USA O'Reilly Japan O'Reilly Taiwan