Linux Shell Scripting Basics

Decades ago, when the Unix operating system appeared on the computing scene, there were no graphical user interfaces (GUIs), designed to make working with the computer easier. There were no drop-down list boxes, collapsible directory trees, scrollbars, or blinking lights on the screen (aside from the edit cursor). In fact, the only mice to be found in the computer room would be those nesting in the warmth of a computer cabinet in need of cleaning.

In a non-graphical environment, all instructions to the computer are made as text commands, each of which consists of the command name followed by zero or more options, which modify what the command will do. For example, the Linux command "ls" can be used to list files in the current directory. "ls -l" will do the same, but present the file list in long format, i.e., displaying additional details for each file.

Nowadays, an ever-growing number of PC users are jettisoning Windows, in favor of Linux, as their operating system of choice. Because Linux is essentially Unix for the PC, it should come as no surprise that Linux has the same command line capabilities as its ancestor.

At the same time, many people are switching from PCs to Macs, and thus from Windows to Mac OS X, which has a Linux-like command line as well. In the case of both Linux and OS X, more computer users have the opportunity to work with commands, options, and the shell scripts that can be built from them.

Shell Game

But before I get to some of the details of scripting, I first must be clear as to what a Linux shell is, and which ones you might encounter when exploring the Linux installation on your PC. Simply put, a shell is a computer program that accepts your commands — either typed in at the command line, or stored in a file — and executes those commands, one at a time.

There are several Linux shells available, but just a few major ones with which you should be familiar. The default shell for the majority of Linux distributions is "bash". The name is derived from "Bourne-Again SHell", which is a play on words, because bash is a descendent of one of the original shells, "sh", developed by Stephen Bourne.

Other shells include KornShell, "ksh", developed by David G. Korn, who added some much-needed features to sh. Berkeley C shell, "csh", developed by Bill Joy, has a unique style, heavily influenced by the C programming language. A better incarnation of it is "tcsh".

When you open a shell window in Linux, you will be presented with some sort of command line prompt, such as a "$", which is Linux's way of telling you that it is ready for you to type in a command. The first command you might want to try is "echo $SHELL", which tells you which shell you are currently using.

If at any point you would like to try a different shell, you can see which ones are available on your system: "cat /etc/shells". To get any one of them started, simply enter the shell name as a command. You will then be presented with that shell's command prompt, which may be identical to your previous one. If you were then to leave that new shell (such as by entering the "exit" command), you would then be back to your previous shell.

Example of Shell Scripting

As you become more familiar with the many Linux commands available, you may find yourself entering the same commands repeatedly. To save yourself the time of retyping them, you can store them in a file. Such a file of Linux commands is referred to as a "shell script" or a "script". The Linux shell can then be instructed to run all of the commands that comprise a script.

For example, the following is a simple but complete shell script that scans through all the files in the current directory, and lists each one in long format:

#! /bin/bash
                for file in `ls -1`; do
                    ls -l $file
                done

(Admittedly, the script can be replaced with a single command, "ls -l", but this is for illustration purposes only.)

Let's examine this script and see how it works. The first line, which begins with "#", is a comment. When Linux reads that line, it ignores everything to the right of the "#" comment symbol.

Comments do not alter what a script does, and are not necessary. But it is always wise to explain what your script is doing (or supposed to be doing!). That may seem unnecessary in such a simple script as this one, but in more complex scripts, comments are invaluable.

The second line, which begins with "#!", may look like a comment, but it is a special symbol that informs Linux which shell to run on the script — in this case, bash, located in the bin directory.

The "for… do… done" statement executes everything inside of it for each value returned by the "ls -1" command, namely, a file name, which is assigned to the variable "$file" each time.

If this script file were named "lister.bash", you could execute it from the command line. First make the script executable: "chmod +x lister.bash". Then instruct Linux to run the script: "bash lister.bash" or ". lister.bash".

Further Study

A short article can only scratch the surface of Linux shell scripting. Fortunately, there are countless resources to which the aspiring shell programmer can turn. Some books available include Classic Shell Scripting and Learning the bash Shell, both published by O'Reilly Media.

To learn more about any Linux command, first try the online manual. For instance, to read all of the options available for the "ls" command, simply type in "man ls". To read the output one page at a time, simply pipe the output through the "more" command, if needed: "man ls | more".

If you would like to do some shell programming, but you do not have a PC running Linux, you could boot off of a Linux "live CD", such as Knoppix, and open up a shell window once Knoppix has completed its start-up process.

Another option is to get a shell account on a Unix or Linux server on the Internet. One example is SDF, which offers Unix shell accounts at no cost.

Once you begin writing your own shell scripts, you will likely see how powerful and useful they can be, as well as why so many of the Unix veterans consider GUIs to be overrated eye candy.