| A number of shells are available and, in general, users will just get used to using the one they are assigned by their system administrator. They may not know which one they are using, or even be aware that alternatives exist. Around 15 years ago when we began using UNIX, the choice was really between two shells: the Bourne Shell (/bin/sh) or the C Shell (/bin/csh). The general consensus at the time was that the Bourne Shell was the easier of the two to use. It had a simple interface and was less cryptic than the C Shell for writing shell scripts in. The scripts were also more portable across different flavors of UNIX. The C Shell had a syntax very similar to the C language so C programmers tended to favor it, but everyone else tended to use the Bourne Shell. The C Shell, however, did have one big advantage over the Bourne Shell and that was its command line history and editing facilities. The C Shell could be told to keep a list of the commands you had typed in and allow you to rerun them without all the effort of retyping them. More useful, though, was the ability to alter lines so if you had typed in a long command but mistyped something you could correct and rerun the line with a few keystrokes. Though this was not a particularly intuitive interface, once learned most people found it very useful. At the time, most of my colleagues and I preferred to use both shells. We would use the C Shell as our login shell, but write shell scripts using Bourne Shell syntax. There are two ways of running a shell script. The first is to provide it as an argument to the shell command itself (i.e., sh script_name would cause the Bourne Shell to run the script and csh script_name would cause the C Shell to run it). This way allows you to run a Bourne Shell script from within a C Shell, but it is rather a pain and it would be better if you could run your script in the same way as other UNIX commandsby just typing their name. It is possible to do this if you first set execute permission on the shell script. The problem now is that if you type the script name from a C Shell prompt, the C Shell will try and run it itself (which will result in a serious number of syntax errors if it is a Bourne Shell script). What was needed was a way of specifying which shell should run a script without you needing to type it in each time you wanted to run it; fortunately a method existed. You could simply type "#!" followed by the full path of the shell you wished to use at the very start of your script. The following at the start of a script identifies it as a Bourne Shell script; any shell would know how to run it: #! /bin/sh This may lead you to conclude that you should also use the C Shell for interactive work and the Bourne Shell for scripting, but this was some time ago and things have changed since then. The Bourne Shell and C Shell still exist and are still widely used. However, a number of other shells have been added to their ranks. Most started off in the public domain and some were picked up by UNIX vendors and incorporated within their UNIX offering. Solaris offers a choice of the following shells: The Bourne Shell offers a simple interface with a standard and noncomplex scripting language. The C Shell offers a powerful user interface and complex scripting language. The TCSH Shell is based on the C Shell but with additional features such as spelling correction. The Korn Shell offers a powerful and simple user interface, is fully compatible with the Bourne Shell for scripting, and offers useful extensions. The Job Shell is the Bourne Shell with added job control commands that enable you to manipulate jobs (commands or programs) while they are running. The Z Shell closely resembles the Korn Shell and provides some enhancements. The Bash Shell (Bourne Again Shell) began life in the public domain and is similar to the Korn Shell, but with some extensions. The shell you choose depends upon many factors and to some extent it is not too important. Many organizations tend to standardize on the Korn Shell since it is widely available, is fully compatible with the Bourne Shell, and tends to be the most widely used. We will use the Korn Shell for all scripts and examples within this book. This chapter will contain a few references to other shells when appropriate. Whatever shell you choose to provide for your users, it is important that you don't change the shell used by the root user. This is because most shells available in Solaris are dynamically linked. This means that when they are compiled, instead of all the libraries used in the code being included within the final executable file they are loaded as they are needed while the executable program runs. The advantage of this includes the fact that the executable will be smaller and will therefore take up less memory when it runs. Also, if any dynamic libraries are updated the executable will not need recompiling to include them. The downside of using dynamically linked libraries is that if they are missing for any reason, programs that need to use them will not be able to run. These libraries are located in the /usr filesystem so if this became corrupt or inaccessible, root would not be able to fix the problem if it had a dynamically linked shell. To avoid this problem, the shell /sbin/sh is statically linked so root should always have this one set in the /etc/passwd file (see Chapter 3, "User Administration"). It is also a good idea not to use a shell with a history facility for the root user, as it is easy to accidentally select the wrong command from the history list. This could cause all sorts of problems, as UNIX assumes you know what you are doing and tends not to ask if you really want to do something. And remember, root has permission to do anything. | 
