unx14.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>switch statement</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>until statement</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>set -<I>x</I></P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>set optionname</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>Set-uid scripts</P>

<TD>

<P>-</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>Shell functions</P>

<TD>

<P>SysV</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>Substring selectors :<I>x</I></P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>trap command</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>typeset command</P>

<TD>

<P>-</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>ulimit command</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>Undefined variable is an error</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>! special character</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>@ command</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>*(...) wildcards</P>

<TD>

<P>-</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>$(...) command expression</P>

<TD>

<P>-</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>{...} wildcards</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P>

<TR>

<TD>

<P>|&amp; coprocessing</P>

<TD>

<P>-</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TR>

<TD>

<P>&gt;&amp; redirection</P>

<TD>

<P>-</P>

<TD>

<P>X</P>

<TD>

<P>-</P></TABLE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B>  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.

<BR></NOTE>

<HR ALIGN=CENTER>

<H3 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=4><B>Shell Scripts for Public Consumption</B>

<BR></FONT></A></CENTER></H3>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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:

<BR></P>

<UL>

<LI>For really important projects, choose any shell language (or other tool) you want&#151;your choice simply becomes another requirement for installation and use of the system. (Don't forget to tell your user community of such requirements.)

<BR>

<BR></LI>

<LI>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.

<BR>

<BR></LI>

<LI>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.

<BR>

<BR></LI>

<LI>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.

<BR>

<BR></LI>

<LI>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.

<BR>

<BR></LI></UL>

<H3 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=4><B>Summary</B>

<BR></FONT></A></CENTER></H3>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

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

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P><A HREF="unx13.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>

<A HREF="index.htm"><IMG SRC="blutoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>

<A HREF="unxpt3au.htm"><IMG SRC="blunext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>

<A HREF="index.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Home"></A>

</P></BODY></HTML>