发信人: jerk (徐子陵), 信区: Unix
标  题: Unix Unleased -14
发信站: 饮水思源站 (Fri Nov 20 20:13:57 1998) , 站内信件

    
    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: 

    As a keyboard interface to the operating system 
    
    
    As a vehicle for writing scripts for your own personal use 
    
    
    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




            
            Bourne13313
            C22132
            Korn31221
    
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




            
            Arithmetic expressions-XX
            Array variables-XX
            Assignment id=stringX-X
            case statementX-X
            cdpath searchesSysVXX
            clobber option-XX
            Command aliases-XX
            echo -n option-X-
            export commandX-X
            foreach statement-X-
            getopts built-in command--X
            glob command-X-
            Hash table problems, rehash and unhash commands-X-
            Job control (bg, fg, ...)-XX
            let command--X
            limit, unlimit commands-X-
            nice shell built-in-X-
            nohup shell built-in-X-
            notify shell built-in-X-
            onintr command-X-
            print command--X
            pushd, popd commands-X-
            RANDOM shell variable--X
            repeat shell built-in-X-
            select statement--X
            setenv, unsetenv commands-X-
            SHELL variable specifies command to execute scripts-X-
            switch statement-X-
            until statementX-X
            set -xX-X
            set optionname-X-
            Set-uid scripts--X
            Shell functionsSysV-X
            Substring selectors :x-X-
            trap commandX-X
            typeset command--X
            ulimit commandX-X
            Undefined variable is an error-X-
            ! special character-X-
            @ command-X-
            *(...) wildcards--X
            $(...) command expression--X
            {...} wildcards-X-
            |& coprocessing--X
            >& redirection-X-


NOTE: In the preceding table, SysV indicates the feature is available in the 
Bourne shell only for System V variants; it is not a feature of the Version 7 
shell or the BSD implementation of sh. The Version 7 implementation of sh may 
entail restrictions not reflected in this table. 



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. 

    

--

         隋末风云起，双龙走天下。
         尽数天下英豪，唯我独尊！ 

※ 来源:·饮水思源站 bbs.sjtu.edu.cn·[FROM: 202.120.5.209]
--
※ 修改:．fzx 于 Aug  1 12:22:35 修改本文．[FROM: heart.hit.edu.cn]
※ 转寄:．紫 丁 香 bbs.hit.edu.cn．[FROM: chen.hit.edu.cn]

--
☆ 来源:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: jmm.bbs@bbs.hit.edu.]