Writing small program
s in the language
of the command line interpreter
The power of shell scripting accounts for the popularity of the command line interface, for which Unix and its variants such as Linux are well known.
Shell scripting can of course be used in any software environment with
- a shell
- a program that offers the user a working environment, a interface to certain programs, utilities, or other functionality
- the possibility to save simple or complex sequences of user actions as special programs ("scripts"), which can then be run as a single action
A shell can be graphical (for example, the Windows Explorer in Microsoft Windows). Scripting in such environments can be done at various levels of abstraction: the surface level of mouse and keyboard clicks, the user interface level of button clicks, menu selections, etc., or the application level, where the script would be written in terms of application functions. Simple scripts are often called macros; we speak of scripting when the result is a script, a real program that can be edited on its own and that may contain program logic such as conditional execution, iteration, etc.
Many shells aren't graphical, but offer a command line interface; such as shell is a command line interpreter. Unix shells such as sh, bash, csh, tcsh, zsh fall into this category; another example is the Tcl shell, wish. On Windows the traditional shells are COMMAND.COM and CMD.EXE.
With command line interpreters, interactive use seamlessly leads to scripting: sequences of commands that become tedious to repeat can simply be saved to file as a script, after which the script can grow further into a more general and powerful program.
Shell scripting was an important Unix feature from the beginning; for example, the startup procedure on a Unix (or Linux, ...) system consists largely of shell scripts. This has led to a tradition that is often called the "Unix toolbox philosophy": if you add new functionality, make sure it is easy to script, by implementing it as a collection of many small, special-purpose utilities, and gluing them together with shell scripts. That way, the overall logic of the application is self-documenting (people can just read the shell scripts) and proficient users can adapt the shell scripts for their own use, or create their own for new applications.
A simple example is the "fast find" utility for filenames that comes with many Unix variants. It has two parts: the indexer, updatedb,
and the command to search for things in the index, locate. It is possible to use locate in your own shell scripts. But updatedb is itself a shell script, built on several smaller tools, which means anyone can take it apart and create a modified version; which I have done on some machines.
The antithesis of this approach is the large monolithic program that you simply have to start up and use. On Unix, commercial applications tend to fall in this category, and the first major free applications of this kind were web browsers such as Mosaic, Netscape and Mozilla. A more interesting example is Emacs, which is a scriptable shell of its own, but isn't amenable to Unix shell scripting.
The power of shell scripting is limited by the shell's programming paradigm. Unix shells, for instance, assume imperative programming, with some added support for concurrent execution; they are not a good fit for many modern environments, which really require an object oriented description, in which objects create and destroy other objects, and call each other's methods.