The shells and specifically bash

From Linux 101, The beginner's guide to all things Linux.

Contents 1 What is a shell? 2 The common Linux shells 3 Pipelines 4 Backgrounding programs 5 Running several tasks 6 Conditionally running tasks 7 Saving program output to a file 8 Further information

[edit] What is a shell?

Coming from Windows you have seen a shell: The MS-DOS Shell. This was the only common shell in Windows. Even it had some useful, and sometimes powerful abilities to it.

The purpose of a shell is to act as a go between the user and the operating system when it comes to program execution. At first this may be a little daunting, because you have to learn how to talk to the shell. Once you learn how to communicate with the shell, it will work for you and be your henchman on the computer.

[edit] The common Linux shells

• sh
• csh
• tcsh
• ksh
• bash

sh is the standard shell interpreter. This means sh is often used on script files, but not as an interactive shell where you type your commands. csh is a shell that is modeled after the C language in its syntax. The tcsh is like an extended csh. ksh is also another good shell.

It is a bit humorous, but all of the shells boast that they have the same features as one another, and more! So which is the best? That is a question you can best answer yourself. Unless you are a programmer, bash is the best choice for you. If you are a programmer, then you may wish to look into the others, as they may be more to your liking.

Again, there is no correct shell to use, it's just a matter of opinion. The rest of this article will focus on the bash shell, since it is predominantly the default shell (since it is the GNU shell and the others are not). With that in mind, let's start learning about the basics of the bash language, so that you can make a worker out of your shell.

[edit] Pipelines

Pipelines are a way for one program to dump its output into another program. Traditionally, you would have to run the first program and dump it into a file. Then you would have to do something with that file via a second program. This process can skip the output to a file because of pipelines.

Let's say you want to run

ls -la

in a directory that has 500 files, and you are searching for a particular file but you cannot remember the specifics about it. Now it would be convient to scroll up, but the whole list is not showing up in your terminal, so you can't see every file listed. This is no use to you, but you remember the pipe operator, and you type in:

ls -la | less

Suddenly you see the list you needed, and you can scroll through it with the arrow keys. What has happened?

Bash ran your program ls -la but instead of writing it to the terminal screen, it sent it to the program less. less is a very useful program for looking through a long file or output. It (like other programs discussed) follows the basic vim commands outlined on our man pages article.

Note: There is also another program called more. Try it in place of less and see the difference.

Thanks to the pipeline operator, you could easily see all of your output.

Another great program used in conjunction with the pipeline operator is grep. It is discussed in further detail on its own page, but here is an example of grep in action.

ls -la | grep <word to search for>

example ls -la | grep CLUG

ls -la | grep "<phrase to search for>"

example ls -la | grep "Clemson Linux" | less

Here, grep is a searching program, and will only show lines of the input pipeline that have a match to your search word or phrase.

Notice that you can also use multiple pipes. The second example pipes the output from ls to grep then that output to less to make it easy to view an extensive list which matches the string you were searching for.

[edit] Backgrounding programs

From time to time there are tasks that you will want to run in the background. Running things in the background allows a task to be completed without it controlling the shell.

A prime example of this is updatedb. It scans your harddrive and writes a list of all files into a special database that makes it very fast to search for files on your system. As root you could run:

updatedb

and sit and wait for it to complete before you can use the shell again, or more wisely you could have done:

updatedb &

This trailing ampersand is your way of telling bash that you want this process to fork, the technical term for it to branch away from the shell that started it, but keep running in the background.

If you have already started a process and realize it will take longer than you thought to complete, you may pause the process by hitting Ctrl-Z then put it into the background by typing "bg". This is further explained on Processes and signals

[edit] Running several tasks

Let's say you have several tasks to run. Each has to be run after the other in order. Now you could type in one command, hit enter, wait for it to complete, then type in the second command, hit enter, wait for it, and so on.

The prefered method would be to type in all of the commands at once and then be able to walk away from the computer for awhile. You know it will take a little time to complete these tasks, but why should that keep you near the computer needlessly? Thankfully bash can handle this. At the shell, you would want to type something of this fashion:

program1 <arguments> ; program2 <arguments> ; program3 <arguments> ... and so forth.

The semi colon separator tells bash to execute each program consequatively in the order you give.

Note: Before you hit enter it is often a good idea to check for typos. Bash will only inform errors when it tries to execute the program, not when you hit enter at the beginning. You do not want to come back to the computer to see it has not completed what you wanted it to, so always double check. Note: the above example is a good explanation why on Linux you use a colon : to separate directories, for example in $PATH. This is done because the semi-colon ; is used to parse where one command ends and another starts.

[edit] Conditionally running tasks

At some point you will probably have a situation similar to the previous section, but you will only want to continue if each step completes successfully. Again, you can use bash to accomplish this.

program1 <arguments> && program2 <arguments> && program3 <arguments> ...

A simple example at this point could be:

make && make install

This example will try to run make install only after it has successfully compiled it. If the compile fails, make install will never be run.

Likewise, what if you would only like to run a second program if the first one fails?

make || make clean

If your program compiles successfully, then nothing else will happen. The shell prompt will appear again for you to type at. However, if the compile does fail, bash will then run make clean to empty out the temporary work it created.

[edit] Saving program output to a file

Perhaps it is useful to save a program's output into a file. This could be done for many reasons.

program <arguments> > filename

Bash will run program and whenever the program tries to write to the standard output, it will instead write to filename in the current directory. The program output is not displayed in the shell. You could consider this similar to pipelines, except instead of another program getting the pipeline, a new file is created.

Note: It is important to emphasize that a new file is created. If filename exists in your current directory, it will be overwritten. If you would prefer to append text to your existing file rather than overwrite it, exchange the > operator for >>.

Often times you may see something like this:

program <arguments> > /dev/null

This is our first view of using something in the /dev directory. This construction tells bash to run the program, but to dump its output into the /dev/null. This is the same thing as saying you do not want to see the output of the program at the shell, because no matter what it says, it is not important that you see it.

[edit] Further information

The shells are extensive tools. The man page for bash alone is a lengthy read since it describes everything the shell is capable of doing. Bash will be revisted in future articles, covering this information, but this is a good amount for now.

If you have a particular example of the information above that you use often, tell others about it.

The Bash Articles Series
The shells and specifically bash | The bash environment | Processes and signals | Simple shell scripts | Shell scripting