Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Introduction COSC 101

Introduction COSC 101

Most senior students who supervised introductory computer science labs at Brock University back when I was there kicked their feet up on the front desk with a calculus book cracked open and growled when their homework was interrupted by a question. As anyone will tell you, I never fit the mold of the typical student. In my first lab, I put together a short booklet covering all the questions I had when I took my first lab in COSC 101; namely what was that funny prompt drawn in flickering green on the ailing terminals and how the heck can you use it to give yourself a cool nickname like VAX Dude in the DEC VMS process?

I inadvertently left a pile of my booklets behind and the next day one of the other supervisors stomped up to me and angrily waved one in my face. Her class wanted to know why she hadn't covered any of the material in the booklet. Doing an introductory lesson in shell usage in the first lab would have cut into her homework time, and I had better make sure it did not happen again. It didn't, and my lab students gained about a three-week advantage over the others in view of the fact they didn't have to learn the development environment piecemeal between assignments.

Many books, and many teachers, try to separate computer languages from the environment in which they run. That's like talking about cooking an egg without indicating whether the egg will be cooked in a microwave oven, fried in a frying pan, or boiled in a pot of water. The environment affects what you can do and how you can do it. This is also true with shells.

So don't let a disgruntled supervisor prevent you from getting your feet grounded in the fundamentals. Like my first-year lab booklet, this chapter provides background information on where the Bourne Again Shell came from and why it was developed. Shell programming has its own unique mindset and a quick review is never a waste of time.

Notation Used in This Book

The following standard notations have been adopted for this book for introducing new terms, describing command syntax, and so forth.

  • Italics emphases points in the text and new terms

  • A non-proportional font represents sample Bash scripts, commands, switches, filenames, and directories

  • Bash is an acronym but is written without all capitals for readability

  • Control-K represents a key combination created by holding down the Ctrl key and then pressing the K key before releasing the Ctrl key

  • The Return key refers to the carriage return key, marked Return or Enter depending on your keyboard

  • A non-proportional italic font indicates a value to be substituted with the appropriate text. For example, in -o file, the word file should be substituted with the appropriate file for the switch.

The Origin of Bash

A shell is a program that runs operating system commands. Using a conventional desktop, the user selects an item with the mouse and then applies an action to it, such as highlighting an icon and choosing to copy it. In a shell, the person types instructions (or actions) followed by the targets and any special options. This counterintuitive interface can confuse new users who are used to conventional desktops.

The first Unix shell was the developed by Steven R. Bourne in 1974 for the Seventh Edition of Unix. Called the Bourne shell (or sh) in honor of its creator, it set the standard for Unix shells, including the default dollar sign ($) prompt common to most shells.

Users frequently had to type the same commands over and over again. Writing a program to repeat their commands required a high-level language like C. Instead, it was useful to compose a list of commands for the shell to execute, as if the shell was following a well-rehearsed script. With the addition of features to make simple decisions and loops, these shell scripts could run commands and determine whether they succeeded or failed, taking appropriate action, without resorting to a different language. When commands are combined in new ways in a script, a script conceptually becomes a new command. Scripts can customize and extend operating systems.

Designed to be as small and as open as possible, any feature that did not have to be built into the shell wasn't. Even arithmetic was performed by other programs outside of the shell. This slowed the shell, but speed was not an important factor when the shell spent most of its time waiting on other programs or on the user. To the shell's advantage, if a user needed new or better capabilities, the user could write additional scripts to provide those additional capabilities.

Many rival shells began to appear, offering improvements in speed and capabilities. Two of the most common successors were csh, a shell loosely based on the C language, and the Korn shell (ksh), an improved Bourne shell developed by David G. Korn. Shell designers incorporated commands into the shell for better speed and portability and to make the shells easier to work with. Successful features were freely copied between shells as they matured.

An enhanced version of the Bourne shell was developed as part of the GNU project used by the Linux operating system. The shell was called Bash (for the pun “Bourne Again Shell”). This shell was compatible with the original shell created by Steven R. Bourne, but included many enhancements. It was also compliant with the POSIX standard for shells.

Bash is the standard shell provided with most Linux distributions, including Red Hat, SuSE, Mandrake, Slackware, and UnitedLinux.

When Is a Program a Shell Script?

A script is similar to a program but there is no formal definition for what constitutes a script. It is a type of simple program, and scripts and programs share many features in common. Linux programmers with few special requirements never advance beyond writing shell scripts.

As shells matured, they gained many features that you might not expect to find in a program designed to schedule commands. Most shells, including Bash, can perform bit manipulation, string processing, and TCP/IP connections. They have typed variables, built-in commands, and user-defined functions. The distinction between shells and programming languages has become blurred.

In general, there are two key differences between shell scripts and more complex programs. First, shells are designed to handle short, simple tasks. They lack the rigid structure and semantic checking of a high-level language. Shell scripts can be written quickly because they assume the programmer knows what he or she is doing, and for short scripts, this is usually true. Second, shells always execute their scripts slowly. Although most shells perform some kind of pre-processing to speed up execution, they still interpret and carry out one line at time. High-level languages are faster because they almost always translate a program into machine language to gain the best performance.

When tackling any programming problem, it's essential to choose the right tool for the job. Developing large projects as shell scripts will mean your project will run slowly and be difficult to maintain. Developing scripts in a high-level language will lead to a longer and more costly development time.

The Necessity of Structured Shell Programming

Shell scripts remain a staple of the business world. With high development costs, it is not practical to develop everything in a high-level language. Many business processes are simply a matter of following a series of steps, after which the results are labeled and archived. This is the very type of activity scripts are made to handle.

Over time, shells have collected new features, often by copying the capabilities of other shells. In his book, The Humane Interface, Apple Macintosh interface designer Jef Raskin once spoke with a pilot regarding the design of the plane's autopilot. The device was designed with five ways to enter coordinates. The reason for this design was to reduce training costs by emulating other autopilots. However, a pilot pointed out that the operator of the aircraft is responsible for knowing how to operate every piece of equipment, and that meant he had to know how to adjust the autopilot in each of the five ways.

Many shells, including Bash, have developed a mixture of features with specialized or arcane applications. Like the autopilot, it is not always clear how these features should be used nor which features are provided primarily for compatibility. Too often, poorly designed scripts are all-but illegible to another programmer, or even to the same programmer a few months after a script was hastily assembled.

This presents a problem for serious business scripts. The cost of developing a high-level language solution is high, but a disorganized shell script can be expensive to maintain over time. As the needs of the business change, and the shell script is modified by successive generations of programmers, the problem escalates.

As a rule of thumb, business programs never go away. At one place I recently worked, what started off as a simple shell script used to print reports gradually evolved into a Web-based reporting system complete with personal customizations and secure access. The original programmer had no idea what his script would become.

Because of the essential openness and complex syntax of Bash, it's to the benefit of any serious project to adapt some kind of standard. Bash is very forgiving, but the costs are not. For example, there are many ways to add 2 + 2 in Bash. Like the autopilot anecdote, it's not practical to expect the programmers who maintain the scripts to have to deal with this kind of redundancy.

Likewise, shell word quoting is sometimes optional, sometimes required, depending on the context. A command that works with one form of quotation can suddenly stop working when different data appears in the quotes.

Issues like shell word quoting, specialized capabilities, or portability features, when abused, can lead to increased maintenance and long-term development costs.

Installing Bash

Bash is the standard shell on most Linux distributions. However, there are other Linux shells available and there's no requirement that Bash should be present on any particular distribution.

The Bash shell is open source software released under the GNU Pubic License (GPL). If you need to install Bash, the C language source code is freely available from the Free Software Foundation at http://www.gnu.org or through one of its download mirrors.

The Bash installation procedure can vary over time. Complete instructions are found in the README file that accompanies the sources. However, the installation is largely automated. The basic procedure is as follows:

1.
Run the configure program to determine your operating system and verify the features necessary to compile Bash.

2.
Run make to build Bash.

3.
Run make tests. This will run diagnostic tests to ensure Bash was built properly.

4.
Run make install to install Bash under the /usr/local/ subdirectory.

Assuming your PATH variable is set correctly, you can start Bash by typing bash at the shell prompt.

If you do not have superuser privileges on your computer, you can still compile and install Bash under your personal account. Use the — prefix option with configure to specify the directory to install Bash in. For example, —prefix=$HOME or —prefix=$HOME/bash might be good choices.

Bash and Other Scripting Tools

Ksh, Perl, and Python are similar, but not identical, to Bash.

The Korn shell (ksh) is an enhanced version of the Bourne shell. A public domain version exists called pdksh. Korn shell is a popular shell on many commercial Unix systems. Most, but not all, of the Korn shell's features work under Bash. Both shells can do bitwise arithmetic, for example. Some features have different names. The Korn shell built-in print command is a rough equivalent to the Bash printf command, and the Korn shell whence command is equivalent to the type command. A complete list of differences and porting issues is available in the Bash FAQ at http://www.faqs.org/faqs/unix-faq/shell/bash/.

Perl (Practical Extraction and Report Language) is, as its name suggests, a scripting language for generating reports. It combines the features of a shell language, the sed command, and the awk command to create a single tool. It is not a shell and Perl scripts are not compatible with Bash.

Python (named after the “Monty Python” comedy troupe) is an interpreted language designed for small projects needing rapid development. It is not a shell, but like Bash, it contains many features designed for interactive sessions. Python scripts are not compatible with Bash.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint