Red Hat | Red Hat Documentation

Download

Online Shop

Red Hat Network

Red Hat Documentation

Shell Collecting
3.1 Shell Collecting

In the olden days (we're talking '60s here), when AT&T;'s Dennis Ritchie and Ken Thompson were designing UNIX, they wanted to create a way that humans could interact with their new system.
Operating systems at the time did come with ``command interpreters,'' which could take commands from the user and interpret them for the computer to understand.
But Ritchie and Thompson wanted something more, something which could offer better features than the command interpreters of the day.
Enter the Bourne shell (known simply as sh), created by S.R. Bourne, which fulfilled the goals of UNIX's creators.
Since the creation of the Bourne shell, other shells have been developed, such as the C shell (csh) and the Korn shell (ksh).
When the Free Software Foundation sought a royalty-free shell, developers began to work on the language behind the Bourne shell as well as some of the popular features from other shells available at the time.
The result was the Bourne Again Shell -- or bash.
By now, of course, you've probably seen the word bash when you've mistyped commands at the shell prompt (as in bash: oops: command not found).
In Chapter 1, when we covered redirection and piping, we were also demonstrating the power of bash.

Tip: You can learn more about bash by reading the bash man page. At the shell prompt, type man bash (or you can save the file as a text file by typing man bash | col -b > bash.txt, which you can then open to read with an editor like pico or a pager like less. You can also print the file with man bash | col -b | lpr, but be warned: it's a large file. If you want more information, O'Reilly & Associates publishes Learning the bash Shell, by Cameron Newham and Bill Rosenblatt.

Although your system came with several different shells, bash is the default shell for Red Hat Linux.
You might think of bash as a fleet-footed office assistant who has made a habit of keeping notes on ways to fulfill commands quickly. This assistant also keeps pointers on how you like to customize the way you work.
These ``pointers'' bash keeps are referred to as environment variables.
The shell uses an ``environment'' in the same way we use an environment, like a kitchen. We work in our kitchen, arrange pots, pans, and spices. We know where the dishes are, how things operate.
The same can be said for bash and its environment. There's a basic arrangement to bash as there would be to just about any kitchen. For example, we'd expect to see pots in a kitchen in the same way that we would expect to see certain commands in bash.
That's the idea behind environment variables.
As long as your assistant has the right pointers, he'll fulfill your commands quickly.
Let's take a look at our environment variables. At the shell prompt, type:
env

Quite a few ``shortcuts'' bash uses, aren't there?
Each one of these helps bash customize the environment for you.
Among the most important environment variables is the PATH environment variable -- which defines what is known as the default path.
The PATH environment variable for our account billy might look something like this:
PATH=/usr/local/bin:/usr/X11R6/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/billy/bin

It looks crowded, but the PATH statement is a great signpost, which points to where programs can be found.

Tip: Remember the reference in the previous chapter to the FHS (Filesystem Hierarchy Standard)? The PATH statement is set according to that standard, and programs are installed in directories in accordance with the FHS as well. The end result is that the PATH statement will enable bash to automatically find nearly any program, assuming it has been installed in accordance with the FHS.

Search for: