Any experienced computer user knows that we often end up running basically the same sequence of commands many times over. Typing the same sequence of commands over and over is a waste of time and highly prone to errors.
All Unix shells share a feature that can help us avoid this repetitive work: They don't care where their input comes from.
It is often said that the Unix shell reads commands from the keyboard and executes them. This is not really true. The shell reads commands from any input source and executes them. The keyboard is just one common input source that can be used by the shell. Ordinary files are also very commonly used as shell input.
Recall from Chapter 1, Using Unix that Unix systems employ device independence, which means that any Unix program that reads from a keyboard can also read the same input from a file or any other input device.
Hence, if we're going to run the same sequence of commands more than once, we don't need to retype the sequence each time. The shell can read the commands from anywhere, not just from the keyboard. We can put those commands into a text file once and tell the shell to read the commands from the file, which is much easier than typing them all again.
In theory, Unix commands could also be piped in from another program or read from any other device attached to a Unix system, although in practice, they usually come from the keyboard or a script file.
There is another very good reason for writing shell scripts in addition to saving us a lot of redundant typing:
A shell script is the ultimate documentation of the work we have done on a computer.
By writing a shell script, we record the exact sequence of commands needed to reproduce results, in perfect detail. Hence, the script serves a dual purpose of automating and documenting our processes.
Developing a script has a ratchet effect on your knowledge. Once you add a command to a script, you will never forget how to use it for that task.
Clear documentation of our work flow is important in order to justify research funding and to be able to reproduce results months or years later.
An important part of documenting code is making the code
self-documenting. When writing shell
scripts, using long options in commands such as
zip --preserve-case instead of
zip -C makes the script much easier to
read. While -C is less typing and may be preferable when
running zip interactively many times, we only have to type
--preserve-case
once when writing the
script, so the laziness of using -C
doesn't
pay here.
Imagine that we instead decided to run our sequence of commands manually and document what we did in a word processor. First, we'd be typing everything twice: Once at the shell prompt and again into the document.
The process of typing the same commands each time would be painful enough, but to document it in detail while we do it would be distracting. We'd also have to remember to update the document every time we type a command differently. This is hard to do when we're trying to focus on getting results.
Writing a shell script allows us to stay focused on perfecting the process. Once the script is finished and working perfectly, we have the process perfectly documented. We can and should add comments to the script to make it more readable, but even without comments, the script itself preserves the process in detail.
Many experienced users will never run a processing command from the keyboard. Instead, they only put commands into a script and run and re-run the script until it's finished.
There are many scripting languages to choose from, including those used on Unix systems, like Bourne shell, C shell, Perl, Python, etc., as well as some languages confined to other platforms like Visual Basic (Microsoft Windows only) and AppleScript (Apple only).
Note that the Unix-based scripting languages can be used on any platform, including Microsoft Windows (with Cygwin, for example) and Apple's Mac OS X, which is Unix-compatible out of the box.
Once you learn to write Unix shell scripts, you're prepared to do scripting on any computer, without having to learn another language.