×

Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Learning Red Hat Linux (with CD-ROM), Second Edition
     

Learning Red Hat Linux (with CD-ROM), Second Edition

by Bill McCarty
 

With roughly 20 million users worldwide, Linux is the most talked about success story of open source and free software. Even devotees of Microsoft Windows and Apple's Macintosh are attracted by the unsurpassed stability and flexibility of Linux, but learning a Unix-style operating system can be a daunting task. The second edition of Learning Red Hat Linux

Overview

With roughly 20 million users worldwide, Linux is the most talked about success story of open source and free software. Even devotees of Microsoft Windows and Apple's Macintosh are attracted by the unsurpassed stability and flexibility of Linux, but learning a Unix-style operating system can be a daunting task. The second edition of Learning Red Hat Linux gives newcomers exactly what they need to get started.The book includes a complete Linux system CD-ROM from Red Hat Software, one of the most popular distributions of Linux in the U.S. Once it guides beginners through the process of installing and configuring this software, the book offers a thorough but gentle introduction to the basics of using Red Hat Linux. This new edition has been "upgraded" to cover installation and configuration of Red Hat version 7.2, with improved sections on how to use the GNOME and KDE desktop environments, and how to use the Red Hat Package Manager (RPM). Highlights ofLearning Red Hat Linux include:

  • How to prepare your system for installing Linux
  • How to install and configure Linux
  • How to install and configure the X Window System
  • How to use X and the GNOME and KDE desktop environments
  • How to obtain and set up Linux applications
  • How to set up a Linux system for networking, either on your local area network (LAN), or via a dialup connection to the Internet
  • How to install and configure Linux-based servers, including the Apache web server and Samba for integrated file and print services with Windows-based networks
  • How to understand and write shell scripts to extend the power of Linux
  • How to install, upgrade, and remove packages using RPM

Editorial Reviews

This second edition of a book/CD-ROM guide to installing and running Red Hat Linux on a PC has been upgraded to cover installation and configuration of Red Hat version 7.2, with improved sections on how to use the GNOME and KDE desktop environments and the use of the Red Hat Package Manager. The two CD-ROMs contain tools needed to install and configure a Red Hat Linux system. The book is written for first-time Linux users. McCarty teaches management information systems at Azusa Pacific University. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9780596000714
Publisher:
O'Reilly Media, Incorporated
Publication date:
01/08/2002
Edition description:
Second Edition
Pages:
368
Product dimensions:
7.70(w) x 8.52(h) x 0.99(d)

Related Subjects

Read an Excerpt

Chapter 13: Advanced Shell Usage and Shell Scripts

Like an MS-DOS Prompt window, the Unix shell is a command interpreter that lets you issue and execute commands. By means of the shell, you use and control your system. If you're accustomed to the point-and-click world of graphical user interfaces, you may question the value of learning to use the Linux shell. Many users initially find the shell cumbersome, and some retreat to the familiar comfort of the graphical user interface (GUI), avoiding the shell whenever possible. However, as this chapter explains, the shell unlocks the true power of Linux.

The Power of the Unix Shell

While it's true that the shell is an older style of interacting with a computer than the GUI, the graphical user interface is actually the more primitive interface. The GUI is easy to learn and widely used, but the shell is vastly more sophisticated. Using a GUI is somewhat like communicating in American Indian sign language. If your message is a simple one, like "We come in peace," you can communicate it by using a few gestures. However, if you attempted to give Lincoln's Gettysburg address--a notably short public discourse--you'd find your task quite formidable.1

The designer of a program that provides a GUI must anticipate all the possible ways in which the user will interact with the program and provide ways to trigger the appropriate program responses by means of pointing and clicking. Consequently, the user is constrained to working only in predicted ways. The user is therefore unable to adapt the GUI program to accommodate unforeseen tasks and circumstances. In a nutshell, that's why many system administration tasks are performed using the shell: system administrators, in fulfilling their responsibility to keep a system up and running, must continually deal with and overcome the unforeseen.

The shell reflects the underlying philosophy of Unix, which provides a wide variety of small, simple tools (that is, programs), each performing a single task. When a complex operation is needed, the tools work together to accomplish the complex operation as a series of simple operations, one step at a time. Many Unix tools manipulate text, and since Unix stores its configuration data in text form rather than in binary form, the tools are ideally suited for manipulating Unix itself. The shell's ability to freely combine tools in novel ways is what makes Unix powerful and sophisticated. Moreover, as you'll learn, the shell is extensible: you can create shell scripts that let you store a series of commands for later execution, saving you the future tedium of typing or pointing and clicking to recall them.

The contrary philosophy is seen in operating systems such as Microsoft Windows, which employ elaborate, monolithic programs that provide menus, submenus, and dialog boxes. Such programs have no way to cooperate with one another to accomplish complex operations that weren't anticipated when the programs were designed. They're easy to use so long as you remain on the beaten path, but once you step off the trail, you find yourself in a confusing wilderness.

Of course, not everyone shares this perspective. The Usenet newsgroups, for example, are filled with postings debating the relative merits of GUIs. Some see the Unix shell as an arcane and intimidating monstrosity. But, even if they're correct, it's inarguable that when you learn to use the shell, you begin to see Unix as it was intended (whether that's for better or for worse).

When you are performing common, routine operations, a GUI that minimizes typing can be a relief, but when faced with a complex, unstructured problem that requires a creative solution, the shell is more often the tool of choice. Creating solutions in the form of shell scripts allows solutions to be stored for subsequent reuse. Perhaps even more important, shell scripts can be studied to quickly bone up on forgotten details, expediting the solution of related problems.

Filename Globbing

Before the shell passes arguments to an external command or interprets a built-in command, it scans the command line for certain special characters and performs an operation known as filename globbing. Filename globbing resembles the processing of wildcards used in MS-DOS commands, but it's much more sophisticated. Table 13-1 describes the special characters used in filename globbing, known as filename metacharacters.

In filename globbing, just as in MS-DOS wildcarding, the shell attempts to replace metacharacters appearing in arguments in such a way that arguments specify filenames. Filename globbing makes it easier to specify names of files and sets of files.

For example, suppose the current working directory contains the following files: file1, file2, file3, and file04. Suppose you want to know the size of each file. The following command reports that information:

ls -l file1 file2 file3 file04

However, the following command reports the same information and is much easier to type:

ls -l file*

As Table 13-1 shows, the * filename metacharacter can match any string of characters. Suppose you issued the following command:

ls -l file?

The ? filename metacharacter can match only a single character. Therefore, file04 would not appear in the output of the command.

Similarly, the command:

ls -l file[2-3]

would report only file2 and file3, because only these files have names that match the specified pattern, which requires that the last character of the filename be in the range 2-3.

You can use more than one metacharacter in a single argument. For example, consider the following command:

ls -l file??

This command will list file04, because each metacharacter matches exactly one filename character.

Most commands let you specify multiple arguments. If no files match a given argument, the command ignores the argument. Here's another command that reports all four files:

ls -l file0* file[1-3]

TIP: Suppose that a command has one or more arguments that include one or more metacharacters. If none of the arguments matches any filenames, the shell passes the arguments to the program with the metacharacters intact. When the program expects a valid filename, an unexpected error may result.

The tilde (~) metacharacter lets you easily refer to your home directory. For example, the following command:

ls ~

would list the files in your home directory.

Filename metacharacters don't merely save you typing. They let you write scripts that selectively process files by name. You'll see how that works later in this chapter.

Shell Aliases

Shell aliases make it easier to use commands by letting you establish abbreviated command names and by letting you prespecify common options and arguments for a command. To establish a command alias, issue a command of the form:

alias name='command'

where command specifies the command for which you want to create an alias and name specifies the name of the alias. For example, suppose you frequently type the MS-DOS command dir when you intend to type the Linux command ls -l. You can establish an alias for the ls -l command by issuing this command:

alias dir='ls -l'

Once the alias is established, if you mistakenly type dir, you'll get the directory listing you wanted instead of the default output of the dir command, which resembles ls rather than ls -l. If you like, you can establish similar aliases for other commands.

Your default Linux configuration probably defines several aliases on your behalf. To see what they are, issue the command:

alias

If you're logged in as root, you may see the following aliases:

alias cp='cp -i'
alias dir='ls -l'
alias ls='ls --color'
alias mv='mv -i'
alias rm='rm -i'

Notice how several commands are self-aliased. For example, the command rm -i is aliased as rm. The effect is that the - i option appears whenever you issue the rm command, whether or not you type the option. The - i option specifies that the shell will prompt for confirmation before deleting files. This helps avoid accidental deletion of files, which can be particularly hazardous when you're logged in as root. The alias ensures that you're prompted for confirmation even if you don't ask to be prompted. If you don't want to be prompted, you can issue a command like:

rm -f files

where files specifies the files to be deleted. The - f option has an effect opposite that of the - i option; it forces deletion of files without prompting for confirmation. Because the command is aliased, the command actually executed is:

rm -i -f files

The - f option takes precedence over the - i option, because it occurs later in the command line.

If you want to remove a command alias, you can issue the unalias command:

unalias alias

where alias specifies the alias you want to remove. Aliases last only for the duration of a login session, so you needn't bother to remove them before logging off. If you want an alias to be effective each time you log in, you can use a shell script, which we'll discuss later in the chapter....

Meet the Author

Bill McCarty is associate professor of management information systems in the School of Business and Management of Azusa Pacific University, Azusa, California, and was previously associate professor of computer science, in which capacity he taught for ten years in Azusa Pacific's Master of Applied Computer Science program. Bill holds a Ph.D. in the management of information systems from the Claremont Graduate University, Claremont, California, and worked for 15 years as a software developer and manager.

Customer Reviews

Average Review:

Post to your social network

     

Most Helpful Customer Reviews

See all customer reviews