The shell of a unix type system is a program that runs attached to your terminal and is your interface with the system. The shell not only mediates your requests for the running of other programs with the kernel, but is also the interpreter for a programming language. Each shell has its own language and its own syntactical rules. There are entire books written on each of the shells that describes their use as programming languages.
These pages are not an attempt to fill in for either the manual entries for any of the shells, nor for any of books available. The idea is merely to give a few practical hints, and generalizations that should be enough to get you started writing programs in shell languages, or as they are often called shell scripts.
A shell script is an ordinary readable file whose executable bit must be turned on using chmod +x. If a line begins with a '#' character, that line is a comment. Commenting on your code within a program is always a good idea, especally if the code is not completely obvious. When there are many different shells on a system, there are various ways (not uniform across unix type systems) to let the system (your own particular login shell actually) know which shell your script is written for. If, for instance, your login shell happens to be either 'sh' or 'bash', then having the first line of your file be a single colon will indicate to you shell that the interpreter for your script is one of its kind. To these shells the colon is a "null command". An alternative is sometimes to write as the first line "#!sh" for a script to be run by sh or "#!csh" for a script to be run by the C Shell 'csh'.
The most primitive type of shell script is simply a sequence of commands that you might perform by hand; one line for each command. This is sometimes called, for historical reasons, a "batch file". Often, in this case, it doesn't matter which shell interprets your script. Suppose for example you wanted to write a script that lists all of the programs in /usr/bin that are shell scripts. There is a program called 'file' in unix systems that attempts to tell you what kind of stuff is in a file. Some versions of 'file' are pretty good at even distinguishing the syntax for different shells, others don't know the difference between a shell script and Ovidian poetry, and will claim both to be English text. Play with the one you have available. Let's say that it will always recognize a shell script and will, at least, output the word "commands" for any shell script. We can write the following small script and illustrate a few tricks
: #!sh # listscripts HERE=`pwd` cd /usr/bin file * | grep commands > $HERE/script_list exit 0
The first two lines insure that the script will be run by the bourne shell. The third line is the file name given as a comment. The fourth line shows how to assign a variable a value; that variables don't need to be declared in advance, and that the enclosure by grave accents grabs the standard output of a program, in this case 'pwd'. The fifth line changes the directory of the process, just like a login shell to the desired directory. In the sixth line we do all the work: first run 'file' on every file in the directory /usr/bin, since '*' is th metacharacter that matches any string; pipe the output of 'file' through "grep commands" which will pick out only those lines in the 'file' output that contain the word "commands". Finally the listting which would have been directed to your screen, is redirected to the newly created file with name "script_list" in your current directory. This final step also shows how to retrieve the value of a variable, by preceeding its name with a '$', read as "the value of". Check the man section for sh to see the various locutions that use '$'. Although, in the past, shell scripts exiting successfully have always exited with status zero, it is a good idea to be explicit about it, since the exit status of any program can be captured and contingencies made for different values. A nonzero exit status is usally associated with an error of some kind.
There are many unix utilities, and they can all be used from within a shell script, making the performance of rather high level tasks quite simple. One can, of course, run other shell scripts from within shell scripts, have one shell script be overlayed with another, and design shell scripts that run themselves recursively.