• 14
• Which Shell Is Right for You? Shell Comparison
• Interactive
• Bourne Shell
• C Shell
• Korn Shell
• Shell Scripts for Personal Use
• Shell Scripts for Public Consumption
• Summary

14

Which Shell Is Right for You? Shell Comparison

Most contemporary versions of UNIX provide all three shells—the Bourne shell, C shell, and Korn shell—as standard equipment. Choosing the right shell to use is an important decision because you will spend considerable time and effort learning to use a shell, and more time actually using it. The right choice will allow you to benefit from the many powerful features of UNIX with a minimum of effort. This chapter is intended to assist you in making that choice by drawing your attention to specific features of each shell.

Of course, no one shell is best for all purposes. If you have a choice of shells, then you need to learn how to choose the right shell for the job.

The shell has three main uses:

1. As a keyboard interface to the operating system
   
   
2. As a vehicle for writing scripts for your own personal use
   
   
3. As a programming language to develop new commands for others
   
   

Each of these three uses places different demands on you and on the shell you choose. Furthermore, each of the shells provides a different level of support for each use. This chapter describes the advantages and disadvantages each shell brings to the three kinds of tasks you can perform with it.

Interactive

The first point to keep in mind when choosing a shell for interactive use is that your decision affects no one but yourself. This gives you a great deal of freedom: you can choose any of the three shells without consideration for the needs and wishes of others. Only your own needs and preferences will matter.

The principal factors that will affect your choice of an interactive shell are as follows:

• Learning. It is a lamentable fact of life that as the power and flexibility of a tool increases, it becomes progressively more difficult to learn how to use it. The much-maligned VCR, with its proliferation of convenience features, often sits with its clock unset as silent testimony. So too it is with UNIX shells. There is a progression of complexity from the Bourne shell, to the C shell, to the Korn shell, with each adding features, shortcuts, bells and whistles to the previous. The cost of becoming a master is extra time spent learning and practicing. You'll have to judge whether you'll really use those extra features enough to justify the learning time. Keep in mind though that all three shells are relatively easy to learn at a basic level.
  
  
• Command editing. The C shell and the Korn shell offer features to assist with redisplaying and reusing previous commands; the Bourne shell does not. The extra time savings you can realize from the C shell or the Korn shell command editing features depends greatly on how much you use the shell. Generations of UNIX users lived and worked before the C and Korn shells were invented, demonstrating that the Bourne shell is eminently usable, just not as convenient for the experienced, well-practiced C shell or Korn shell user.
  
  
• Wildcards and shortcuts. Once again, your personal productivity (and general peace of mind) will be enhanced by a shell that provides you with fast ways to do common things. Wildcards and command aliases can save you a great deal of typing if you enter many UNIX commands in the course of a day.
  
  
• Portability. If you will sit in front of the same terminal every day, use the same UNIX software and applications for all your work, and rarely if ever have to deal with an unfamiliar system, then, by all means choose the best tools that your system has available. If you need to work with many different computers running different versions of UNIX, as system and network administrators often must, you may need to build a repertoire of tools (shell, editor, and so on) that are available on most or all of the systems you'll use. Don't forget that being expert with a powerful shell won't buy you much if that shell isn't available. For some UNIX professionals, knowing a shell language that's supported on all UNIX systems is more important than any other consideration.
  
  
• Prior experience. Prior experience can be either a plus or a minus when choosing a shell. For example, familiarity with the Bourne shell is an advantage when working with the Korn shell, which is very similar to the Bourne shell, but somewhat of a disadvantage when working with the C shell, which is very different. Don't let prior experience dissuade you from exploring the benefits of an unfamiliar shell.
  
  

Table 14.1 rates the three shells using the preceding criteria, assigning a rating of 1 for best choice, 2 for acceptable alternative, and 3 for poor choice.

Table 14.1. Ranking of shells for interactive use.

Shell

Learning

Editing

Shortcuts

Portability

Experience

Bourne Shell

I rated the Bourne shell as your best choice for learning because it is the simplest of the three to use, with the fewest features to distract you and the fewest syntax nuances to confuse you. If you won't be spending a lot of time using a command shell with UNIX, then by all means develop some proficiency with the Bourne shell. You'll be able to do all you need to, and the productivity benefits of the other shells aren't important for a casual user. Even if you expect to use a UNIX command shell frequently, you might need to limit your study to the Bourne shell if you need to become effective quickly.

I rated the Bourne shell as lowest in the productivity categories because it has no command editor and only minimal shortcut facilities. If you have the time and expertise to invest in developing your own shell scripts, you can compensate for many of the Bourne shell deficiencies, as many shell power users did in the years before the C shell and the Korn shell were invented. Even so, the lack of command editing and command history facilities means you'll spend a lot of time retyping and repairing commands. For intensive keyboard use, the Bourne shell is the worst of the three. If you have any other shell, you'll prefer it over the Bourne shell.

The C shell and the Korn shell were invented precisely because of the Bourne shell's low productivity rating. They were both targeted specifically to creating a keyboard environment that would be friendlier and easier to use than the Bourne shell, and they are here today only because most people agree that they're better.

However, portability concerns might steer you toward the Bourne shell despite its poor productivity rating. Being the oldest of the three shells (it was written for the very earliest versions of UNIX), the Bourne shell is available virtually everywhere. If you can get your job done using the Bourne shell, you can do it at the terminal of virtually any machine anywhere. This is not the case for the C and Korn shells, which are available only with particular vendors' systems or with current UNIX releases.

I gave the Bourne shell a rating of 3 for prior experience because prior experience using the Bourne shell is no reason to continue using it. You can use the Korn shell immediately with no additional study and no surprises, and you can gradually enhance your keyboard skills as you pick up the Korn shell extensions. If you have access to the Korn shell, you have no reason not to use it.

C Shell

The C shell rates a 2 for learning difficulty, based simply on the total amount of material available to learn. The C shell falls between the Bourne shell and the Korn shell in the number and complexity of its facilities. Make no mistake—the C shell can be tricky to use, and some of its features are rather poorly documented. Becoming comfortable and proficient with the C shell takes time, practice, and a certain amount of inventive experimentation. Of course, when compared to the Bourne shell only on the basis of common features, the C shell is no more complex, just different.

The C shell rates a passing nod for command editing because it doesn't really have a command editing feature. Its history substitution mechanism is complicated to learn and clumsy to use, but it is better than nothing at all. Just having a command history and history substitution mechanism is an improvement over the Bourne shell, but the C Shell is a poor second in comparison to the simple and easy command editing of the Korn shell.

With the Korn shell, you can reuse a previously entered command, even modify it, just by recalling it (Esc-k if you're using the vi option) and overtyping the part you want to modify. With the C shell, you can also reuse a previous command, but you have five different forms for specifying the command name (!!, !11, !-5, !vi, or !?vi?), additional forms for selecting the command's arguments (:0, :^, :3-5, :-4, :*, to name a few), and additional modifiers for changing the selected argument (:h, :s/old/new/, and so forth). Even remembering the syntax of command substitution is difficult, not to speak of using it.

On the other hand, if you like to use wildcards, you'll find that the C shell wildcard extensions for filenames are easier to use—they require less typing and have a simpler syntax—than the Korn shell wildcard extensions. Also, its cd command is a little more flexible. The pushd, popd, and dirs commands are not directly supported by the Korn shell (although they can be implemented in the Korn shell by the use of aliases and command functions). Altogether, the C shell rates at the top of the heap in terms of keyboard shortcuts available, perhaps in compensation for its only moderately successful command editing. Depending on your personal mental bent, you might find the C shell the most productive of all three shells to use. We have seen that those already familiar with the C shell have not been drawn away in droves by the Korn shell in the past.

For portability considerations, the C shell ranks at the bottom, simply because it's a unique shell language. If you know only the C shell, and the particular system you're using doesn't have it, you're out of luck. A C shell user will almost always feel all thumbs when forced to work with the Bourne shell, unless she is bilingual and knows the vagaries and peculiarities of both.

The C shell gets a 2 for prior experience. If you already know it and want to continue using it, I see no compelling reason why you shouldn't. On the other hand, you may be missing a good bet if you decide to ignore the Korn shell. Unless you feel quite comfortable with the C shell's history substitution feature and use it extensively to repair and reuse commands, you might find the Korn shell's command editing capability well worth the time and effort to make the switch. Anyone accustomed to using the Korn shell's command editing capability feels unfairly treated when deprived of it—it's that good. If you haven't already experimented with the Korn shell and you have the chance, I would strongly recommend spending a modest amount of time gaining enough familiarity with it to make an informed choice. You might be surprised.

Altogether, the C shell is a creditable interactive environment with many advantages over its predecessor, the Bourne shell, and it is not clear that the Korn shell is a compelling improvement. Personal preference has to play a role in your choice here. However, if you're new to UNIX, the C shell is probably not the best place for you to start.

Korn Shell

In terms of time and effort required to master it, the Korn shell is probably the least attractive. That's not because it's poorly designed or poorly documented, but merely because it has more complex features than either of the other two shells. Of course, you don't have to learn everything before you can begin using it. The Korn shell can be much like good music and good art, always providing something new for you to learn and appreciate.

For productivity features, the Korn shell is arguably the best of the three shells. Its command editor interface enables the quick, effortless correction of typing errors, plus easy recall and reuse of command history. It's hard to imagine how the command line interface of the Korn shell could be improved without abandoning the command line altogether.

On the down side, the Korn shell provides equivalents for the C shell's wildcard extensions, but with a complicated syntax that makes the extensions hard to remember and hard to use. You can have the pushd, popd directory interface, but only if you or someone you know supplies the command aliases and functions to implement them. The ability to use a variable name as an argument to cd would have been nice, but you don't get it. The Korn shell's command aliasing and job control facilities are nearly identical to those of the C shell. From the point of view of keyboard use, the Korn shell stands out over the C shell only because of its command editing feature. In other respects, its main advantage is that it provides the C shell extensions in a shell environment compatible with the Bourne shell; if Bourne shell compatibility doesn't matter to you, then the Korn shell might not either.

Speaking of Bourne shell compatibility, the Korn shell rates a close second to the Bourne shell for portability. If you know the Korn shell language, you already know the Bourne shell, because ksh is really a superset of sh syntax. If you're familiar with the Korn shell, you can work reasonably effectively with any system having either the Bourne or Korn shells, which amounts to virtually one hundred percent of the existing UNIX computing environments.

Finally, in terms of the impact of prior experience, the Korn shell gets an ambiguous rating of 2. If you know the Bourne shell, you'll probably want to beef up your knowledge by adding the extensions of the Korn shell and switching your login shell to ksh. If you already know ksh, you'll probably stick with it. If you know csh, the advantages of ksh may not be enough to compel you to switch.

If you're a first-time UNIX user, the Korn shell is the best shell for you to start with. The complexities of the command editing feature will probably not slow you down much; you'll use the feature so heavily its syntax will become second nature to you before very long.

Shell Scripts for Personal Use

If you develop any shell scripts for your personal use, you'll probably want to write them in the same shell language you use for interactive commands. As for interactive use, the language you use for personal scripts is largely a matter of personal choice.

If you use either the C shell or the Korn shell at the keyboard, you might want to consider using the Bourne shell language for shell scripts, for a couple of reasons. First, personal shell scripts don't always stay personal; they have a way of evolving over time and gradually floating from one user to another until the good ones become de facto installation standards. As you'll learn in the section titled "Shell Scripts for Public Consumption," writing shell scripts in any language but the Bourne shell is somewhat risky because you limit the machine environments and users who can use your script. Of course, for the truly trivial scripts, containing just a few commands that you use principally as an extended command abbreviation, portability concerns are not an issue.

If you're not an experienced UNIX user and shell programmer, you probably know only one of the three shell languages. Writing short, simple shell scripts to automate common tasks is a good habit and a good UNIX skill. To get the full benefit of the UNIX shells, you almost have to develop some script writing capability. This will happen most naturally if you write personal scripts in the same language that you use at the keyboard.

For purposes of comparison, Table 14.2 describes the shell features that are available in only one or two of the three shells.

Table 14.2. Nonportable shell features.

Feature

sh

csh

ksh

Shell Scripts for Public Consumption

Shell scripts developed for public consumption, whether as some or all the commands of a system, or as installation standard commands for using system facilities, should be designed for enduring portability.

Shell scripts developed for public use are almost always written in the Bourne shell language. Although there is a tendency today to write such scripts in the Korn shell language, people who do so realize they're taking a risk, albeit a modest one.

Some versions of UNIX allow you to specify the shell interpreter to use for a given script file by embedding a special command as the first line of the script: #! /bin/sh as the first line of a script would, on most modern UNIX systems, force the use of the Bourne shell to execute the script file. This is a handy device to allow you to develop scripts in the shell language of your choice, while also allowing users to avail themselves of the script regardless of their choice of an interactive shell. However, the #! device is not available on all versions of UNIX.

Shell scripts written in the C shell or the Korn shell language require that the operating system include the corresponding shell, either csh or ksh. Not all systems meet this requirement, and if portability among several platforms or between current and future platforms is a consideration (that is, if you're writing a script to be used by anyone anywhere, both now and years from now), common sense and reasonable prudence dictate that you avoid C shell and Korn shell syntax constructs in your script.

True portability also limits your use of UNIX commands and command options inside your shell script. Some versions of UNIX, especially the implementation by IBM, offer many new command options on many commands, leading the unwary into developing shell scripts that can run only under the IBM implementation of UNIX. Other versions of UNIX, such as ULTRIX and XENIX, support only the old-fashioned command library, along with some local peculiarities. If you're truly interested in developing portable programs and shell scripts, you should make use of the POSIX and X/Open compatibility guidelines, which describe only commands and command options that are generally available on most UNIX operating system implementations.

Even the dialect of the Bourne shell you use can be a portability consideration. For example, on ULTRIX systems, the command sh supplies only UNIX Version 7 functionality; you have to invoke the command sh5 to run a System V compatible Bourne shell.

Because perfect portability is, like Scotty's transporter, simply not obtainable in the twentieth century, a further application of common sense dictates that the level of effort you invest in portable programming be suitable to the job at hand. You might want to adopt guidelines somewhat like the following:

• For really important projects, choose any shell language (or other tool) you want—your choice simply becomes another requirement for installation and use of the system. (Don't forget to tell your user community of such requirements.)
  
  
• If your shell script might enter the public domain, restrict yourself to the Bourne shell language, and assume a System V Release 1 environment. This provides you with a great many tools but also suits your application to the vast majority of contemporary UNIX installations.
  
  
• If your shell script is targeted for use at your local installation, choose either the Bourne or the Korn shell language. Use the Korn shell if you feel you need its features, but do not use it gratuitously or casually. The odds are heavily in your favor that any future operating system releases or vendor changes will still support your shell script.
  
  
• If your project must meet certain stated compatibility goals (for example, you must support the XENIX machines running at three offices out in Podunk, Nebraska), then by all means adjust your project to meet those goals. There will still be aspects of your project where no stated goals apply. In those cases, choose the level of generality and portability that you (or your project timetable) can afford.
  
  
• In all other cases, choose the tools and languages that you feel permit the most effective, trouble-free, user friendly implementation you can devise, and don't forget to maximize your own productivity and effectiveness.
  
  

Summary

Selecting a shell for use at the keyboard, as an interactive command line processor, is a relatively straightforward task, once you realize that your choice does not affect others. If you are new to UNIX, you should consider using the Korn shell because its built-in command editing feature can significantly increase productivity. Users accustomed to the C shell are also advised to investigate the Korn shell, for the same reason.

Familiarity with the Bourne shell and its capabilities and restrictions is essential for individuals who must work with a variety of UNIX systems or with the general UNIX public. It is the only shell that is universally available under all implementations of the UNIX operating system.

For daily keyboard use, both the C shell and the Korn shell appear to be viable alternatives. The Bourne shell is not a good choice when either of the other two shells is available because its lack of features, especially command history and command editing, degrade personal productivity.

Choosing a shell for writing scripts is, however, a different matter entirely.

Writing shell scripts is a difficult job because it is programming, and as everyone has learned by now, computer programming is not well suited to the human psyche or talents. The need for tools to make the job easier, to catch your mistakes, and to make the best use of your time draws you in the direction of using the most powerful, flexible tools available. If UNIX users had given in to this temptation in the past, seventy percent or more of all existing shell scripts would be written in the C shell language, and all new scripts being written today would be written in the Korn shell language. The temptation, however, is a siren song, and you should allow yourself the weakness of giving in to it only when the cost is small.

Both the C shell and Korn shell offer tools to the script writer that are hard to do without, such as simplified syntax for command substitutions, array variables, variable arithmetic and expressions, and better structured commands such as select. Because these tools are so helpful, they should be used for any work intended only for personal consumption. They should also be preferred for location-specific projects, where the environment can be predicted reasonably accurately. However, for shell scripts claiming a wider audience, the Bourne shell still serves as the lingua franca of the UNIX world and will for some time to come.

The script writer who cannot anticipate the hardware and software environment must consider the choice of commands and command options used in the script as well as the shell language. A few environments offer a wider variety of commands and command options than most, and some UNIX versions omit some of the conventional UNIX runtime features. For most purposes, an implementation compatible with UNIX System V Release 1 can be considered as a minimum portability base. In situations where portability is especially important, the POSIX and X/Open standards should be consulted as guides to available operating system features and capabilities, rather than the vendor's manuals.

Shell programming can be as simple or as complex as you wish it to be. The C shell and the Korn shell are sufficiently sophisticated to permit the implementation of many programs as shell scripts that in the past would have been implemented in the C programming language. The use of shell scripts has also become popular as a prototyping and rapid development method. Indeed, a meaningful and significant amount of programming can be performed even on UNIX not having a compiled programming language.

It would seem that, while one shell can be chosen for customary use at the keyboard, the choice of a shell environment for writing shell scripts needs to be reconsidered for each project.