Learning the bash Shell: Unix Shell Programmingby Cameron Newham
O'Reilly's bestselling book on Linux's bash shell is at it again. Now that Linux is an established player both as a server and on the desktop Learning the bash Shell has been updated and refreshed to account for all the latest changes. Indeed, this third edition serves as the most valuable guide yet to the bash shell.As any good programmer knows, the first/i>
O'Reilly's bestselling book on Linux's bash shell is at it again. Now that Linux is an established player both as a server and on the desktop Learning the bash Shell has been updated and refreshed to account for all the latest changes. Indeed, this third edition serves as the most valuable guide yet to the bash shell.As any good programmer knows, the first thing users of the Linux operating system come face to face with is the shell the UNIX term for a user interface to the system. In other words, it's what lets you communicate with the computer via the keyboard and display. Mastering the bash shell might sound fairly simple but it isn't. In truth, there are many complexities that need careful explanation, which is just what Learning the bash Shell provides.If you are new to shell programming, the book provides an excellent introduction, covering everything from the most basic to the most advanced features. And if you've been writing shell scripts for years, it offers a great way to find out what the new shell offers. Learning the bash Shell is also full of practical examples of shell commands and programs that will make everyday use of Linux that much easier. With this book, programmers will learn:
- How to install bash as your login shell
- The basics of interactive shell use, including UNIX file and directory structures, standard I/O, and background jobs
- Command line editing, history substitution, and key bindings
- How to customize your shell environment without programming
- The nuts and bolts of basic shell programming, flow control structures, command-line options and typed variables
- Process handling, from job control to processes, coroutines and subshells
- Debugging techniques, such as trace and verbose modes
- Techniques for implementing system-wide shell customization and features related to system security
Read an Excerpt
From Chapter 1: bash Basics
It is also possible to redirect the output of a command into the standard input of another command instead of a file. The construct that does this is called the pipe, notated as |. A command line that includes two or more commands connected with pipes is called a pipeline.
Pipes are very often used with the more command, which works just like cat except that it prints its output screen by screen, pausing for the user to type SPACE (next screen), RETURN (next line), or other commands. If you're in a directory with a large number of files and you want to see details about them, Is -1 | more will give you a detailed listing a screen at a time.
Pipelines can get very complex, and they can also be combined with other I/O directors. To see a sorted listing of the file cheshire a screen at a time, type sort < cheshire | more. To print it instead of viewing it on your terminal, type sort < cheshire | lp.
Here's a more complicated example. The file /etc/passwd stores information about users' accounts on a UNIX system. Each line in the file contains a user's login name, user ID number, encrypted password, home directory, login shell, and other information. The first field of each line is the login name; fields are separated by colons (:). A sample line might look like this:
To get a sorted listing of all users on the system, type:
$ cut -d: -f1 < /etc/passwd | sort
(Actually, you can omit the <, since cut accepts input filenamearguments.) The cut command extracts the first field (-f1), where fields are separated by colons (-d:), from the input. The entire pipeline will print a list that looks like this:
If you want to send the list directly to the printer (instead of your screen), you can extend the pipeline like this:
$ cut -d: -f1 < /etc/passwd | sort | lp
Now you should see how I/O directors and pipelines support the UNIX building block philosophy. The notation is extremely terse and powerful. Just as important, the pipe concept eliminates the need for messy temporary files to store command output before it is fed into other commands.
For example, do the same sort of thing as the above command line on other operating systems (assuming that equivalent utilities are available...), you need three commands. On DEC's VAX/VMS system, they might look like this:
$ cur [etc]passwd /d=":" /f=1 /out=temp1
$ sort temp1 /out=temp2
$ print temp2
$ delete temp1 temp2
After sufficient practice, you will find yourself routinely typing in powerful command pipelines that do in one line what it would take several commands (and temporary files) in other operating systems to accomplish.
Pipes are actually a special case of a more general feature: doing more than one thing at a time. This is a capability that many other commercial operating systems don't have, because of the rigid limits that they tend to impose upon users. UNIX, on the other hand, was developed in a research lab and meant for internal use, so it does relatively little to impose limits on the resources available to users on a computer--as usual, leaning towards uncluttered simplicity rather than overcomplexity.
"Doing more than one thing at a time" means running more than one program at the same time. You do this when you invoke a pipeline; you can also do it by logging on to a UNIX system as many times simultaneously as you wish. (If you try that on an IBM's VM/CMS system, for example, you will get an obnoxious "already logged in" message.)
The shell also lets you run more than one command at a time during a single login session. Normally, when you type a command and hit RETURN, the shell will let the command have control of your terminal until it is done; you can't type in further commands until the first one is done. But if you want to run a command that does not require user input and you want to do other things while the command is running, put an ampersand (&) after the command.
This is called running the command in the background, and a command that runs in this way is called a background job; by contrast, a job run the normal way is called a foreground job. When you start a background job, you get your shell prompt back immediately, enabling you to enter other commands.
The most obvious use for background jobs is programs that take a long time to run, such as sort or uncompress on large files. For example, assume you just got an enormous compressed file loaded into your directory from magnetic tape.* Let's say the file is gcc.tar.z, which is a compressed archive file that contains well over 10 MB of source code files.
Type uncompress gcc.tar & (you can omit the .Z), and the system will start a job in the background that uncompresses the data "in place" and ends up with the file gcc.tar. Right after you type the command, you will see a line like this:
followed by your shell prompt, meaning that you can enter other commands. Those numbers give you ways of referring to your background job; Chapter 8, explains them in detail.
You can check on background jobs with the command jobs. For each background job, jobs prints a line similar to the above but with an indication of the job's status:
+ Running uncompress gcc.tar &
When the job finishes, you will see a message like this right before your shell prompt:
+ Done uncompress gcc.tar
The message changes if your background job terminated with an error; again, see Chapter 8 for details...
Meet the Author
Cameron Newham is an information technology developer living in the United Kingdom. After completing a Bachelor of Science majoring in information technology and geography at the University of Western Australia, Cameron worked for Australian Defence Industries for seven years. He is now an IT contractor based in London. In his spare time Cameron can be found surfing the Internet or working on his project to document buildings of architectural interest in England. He also has more than a passing interest in space science, 3D graphics, synthesizer music, and Depeche Mode.
Bill Rosenblatt is author of the the O'Reilly Nutshell Handbook(R) Learning the Korn Shell; coauthor, with Deb Cameron, of Learning GNU Emacs; and a contributor to UNIX Power Tools. He is director of publishing systems at the Times Mirror Company in New York City and acolumnist in SunWorld Online magazine on the World Wide Web. Bill received a B.S.E. from Princeton University and an M.S. and A.B.D. from the University ofMassachusetts at Amherst, each in some variant of computer science. His interests in the computing field include multimedia databases, electronic publishing, and object-oriented systems. Outside of the computing field, he's interested in jazz, classical music, antique maps, and Sherlock Holmes pastiche novels. Bill lives on the Upper West Side of Manhattan. He wishes his landlord allowed pets so that he could truthfully claim to have a dog and cat with suitably droll names like "Coltrane" and "Ravel."
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >
[A review of the THIRD EDITION 2005.] In the last 10 years, it appears that the shell wars in unix and linux have settled down. With bash being the clear favourite. So if you are going to invest your time learning any shell, perhaps you should go with bash and maybe use this book as a helper. It shows that script writing in bash is pretty simple. If you already know another shell, like csh or Korn, then the ideas carry over and so too would most of the syntax. Along the way, the book teaches you more about your operating system. Especially for managing processes/jobs. My background is as a programmer, so I've never been big on shells and their scripting. But others like you may hark from a sysadmin role and prefer shell activity.
Next time label your house. Rides her seahorse away.