| Why Use Shells The Shell History Bourne Shell C Shell Korn Shell Read That Manual! What is a Shell Script Anyway Example Basic Shell Script In The Begining |
The Basic Shells |
Why Use Shells?Well, most likely because the are a simple way to string together a bunch of UNIX commands for execution at any time without the need for prior compilation. Also because its generally fast to get a script going. Not forgetting the ease with which other scripters can read the code and understand what is happening. Lastly, they are generally completely portable across the whole UNIX world, as long as they have been written to a common standard.The Shell History:The basic shells come in three main language forms. These are (in order of creation) sh, csh and ksh. Be aware that there are several dialects of these script languages which tend to make them all slightly platform specific. Where these differences are known to cause difficulties I have made special notes within the text to highlight this fact. The different dialects are due, in the main, to the different UNIX flavours in use on some platforms. All script languages though have at their heart a common core which if used correctly will guarantee portability. Bourne Shell:Historically the sh language was the first to be created and goes under the name of The Bourne Shell. It has a very compact syntax which makes it obtuse for novice users but very efficient when used by experts. It also contains some powerful constructs built in. On UNIX systems, most of the scripts used to start and configure the operating system are written in the Bourne shell. It has been around for so long that is it virtually bug free. I have adopted the Bourne shell syntax as the defacto standard within this book. C Shell:Next up was The C Shell (csh), so called because of the similar syntactical structures to the C language. The UNIX man pages contain almost twice as much information for the C Shell as the pages for the Bourne shell, leading most users to believe that it is twice as good. This is a shame because there are several compromises within the C Shell which makes using the language for serious work difficult (check the list of bugs at the end of the man pages!). True, there are so many functions available within the C Shell that if one should fail another could be found. The point is do you really want to spend your time finding all the alternative ways of doing the same thing just to keep yourself out of trouble. The real reason why the C Shell is so popular is that it is usually selected as the default login shell for most users. The features that guarantee its continued use in this arena are aliases, and history lists. There are rumours however, that C Shell is destined to be phased out, with future UNIX releases only supporting sh and ksh. Differences between csh and sh syntax will be highlighted where appropriate. Korne Shell:Lastly we come to The Korne Shell (ksh) made famous by IBM's AIX flavour of UNIX. The Korne shell can be thought of as a superset of the Bourne shell as it contains the whole of the Bourne shell world within its own syntax rules. The extensions over and above the Bourne shell exceed even the level of functionality available within the C Shell (but without any of the compromises!), making it the obvious language of choice for real scripters. However, because not all platforms are yet supporting the Korne shell it is not fully portable as a scripting language at the time of writing. This may change however by the time this book is published. Korne Shell does contain aliases and history lists aplenty but C Shell users are often put off by its dissimilar syntax. Persevere, it will pay off eventually. Any sh syntax element will work in the ksh without change. Read That Manual!On any UNIX system the on-line documentation available from the man pages covers all the commands available, including the script languages. For Bourne it's usually between 10 and 15 pages whereas for C Shell or Korne it's about 30 pages or more. It is a good idea to get this printed out and put into a loose leaf folder. The on-line documentation is always more up to date than that in the printed manuals that arrive with the system and if stored in normal A4 folders (I use the clear plastic pockets to store the loose pages) this can be used as your reference source. People usually gasp in horror when they hear this - "Why not just open a new window and use man!" - they cry. Well for one thing, if I know the information I want is towards the back, I can jump straight to the page rather than fight with the scrollbar. Secondly, if the information is wrong (Heaven Forbid!) or not too clear (Really?), I can add some of my own clarification in the margins! The all important dialect or platform specifics will also be listed within these man pages. The other thing you must do is cultivate an ability to read through these man pages and understand the meaning behind the words. This is a trick that takes time, don't think for a moment that what is written in a man page is actually correct. It is simply someone else's idea of how to explain what is supposed to happen under known circumstances. Don't forget that it's rare for the code writer to be the documentation writer too. This ability will put you in good stead for negotiating the most troublesome passages. If it doesn't make sense the first time, change your view and look at it from another angle. Develop this skill well, it will pay dividends later. I have included some syntactical information from my man pages within this document but I have kept it to the minimum required and always used examples to explain each concept, something sadly lacking in man pages generally. All examples will be repeated for each shell for comparison when appropriate, although I now only use Bourne shell full time because of its portability (See Bourne Shell and Korn Shell). What is a Shell Script Anyway?:A shell script, in its most basic form, is simply a collection of operating system commands put into a text file in the order they are needed for execution. Using any of the shells mentioned so far, a text file containing the commands listed in Example basic shell script would work every time the script was executed. Example basic shell script#!/bin/sh rm -f /tmp/listing.tmp > /dev/null 2>&1 touch /tmp/listing.tmp ls -l [a-z]*.doc | sort > /tmp/listing.tmp lpr -Ppostscript_1 /tmp/listing.tmp rm -f /tmp/listing.tmp Of course not all scripts are this simple but it does show that ordinary UNIX commands can be used without any extra, fancy scripting constructs. If this script was executed any number of times the result would be the same, a long listing of all the files starting with lower case letters and ending with a doc extension from the current directory printed out on your local PostScript printer. Not very exciting. Lets start to look at this in detail starting at the beginning. In the Beginning:The first line of any script should always look a bit like the top line in Example basic shell script, the only difference would be the path leading to the shell executable file, in this case the /bin/sh part. By default the UNIX system will attempt to execute an ASCII text file if the files name is supplied as the first argument on the command line. UNIX will attempt to execute the file in the current shell, and try to process the included command strings within the file using the syntax rules of the current shell. So, if you are using the Bourne Shell as your default environment and the ASCII file contains a list of UNIX command structures formatted how the Bourne Shell likes them to be formatted, all will work fine. However, if you try and execute a C Shell file with a different syntax structure, the Operating System will complain about unrecognised commands and syntax errors. The reason is, no one told the Operating System that it was a C Shell file, so it processed it as a Bourne Shell. The correct way to indicate this to the Operating System is to pass the script name to the shell executable as an argument thus: user@system$ /bin/csh my_script arg_1 arg_2 However, it didn't take long for someone to notice that this was extra typing that could well be done away with and hence the short hand first Line comment was born (See - Script Example 1.1 ). Basically, all comments in shell scripts start with a hash sign (#). However, for the first line only, UNIX reads past the hash to see what's next. If it finds an exclamation point (!), or Bang!, as it's known, then what follows is taken as the path to the shell executable binary program. Not only that, but all the command line arguments that the shell executable allows can also be stacked up on this line (See - Invocation Flags ). With this feature it doesn't matter what flavour of shell your environment is, you can execute a script in any other flavour of shell, as if it was a real UNIX command. Lets look at the Bourne Shell syntax rules more closely. It would be helpfull at this point to print out the sh man pages from your system so that you can compare them with what I have here. |