- Shopping Bag ( 0 items )
Harness the power of shells . . . for the Internet and beyond
Completely revised and updated to include the latest developments in Internet and business applications, UNIX Shell Programming, Fourth Edition provides comprehensive coverage of Bourne, Korn, C, and BASH shells. Using a specially developed three-step process, this invaluable guide takes you through the entire universe of UNIX shell, from simple commands and programming to the world of software developers and system administrators.
Using this comprehensive book, you'll be able to choose the shell that's right for you -whatever your needs or background.
UNIX Shell Programming, Fourth Edition gives you:
* Practical guidance on how to create CGI scripts, object warehouses, and reuse catalogs
* Everything on shell extensions for management of distributed environments
* A special shell reference appendix containing real-life examples that you can use right now
Visit the book's companion Web site at www.wiley.com/compbooks/unixshell
Revised and updated coverage of the Bourne, Korn, C, and BASH shells, includes Internet and business application scripting. Guides you from simple shell scripts for novices, to advanced scripting for administrators. Covers shell fundamentals, commands, decisions, and repetition, then leads you through user shell programming and structuring concepts. Shows how to prototype and reuse shells. Discusses shell database and system integration, reliability and portability issues, administrative and maintenance duties. Good logically-organized tutorial that first teaches basic skills of shell scripting, then shows how to use these newly acquired skills in productive applications.
After declaring your function it is a simple matter to execute the function; simply type the name of the function just as you would any other command. The Shell locates the function and executes the associated commands. While this is very similar to using other Shell commands or Shell programs that you have written, there are differences.
once the function is declared it is stored in your environment and is executed directly. This differs from the typical command where the Shell must read the file and then interpret the commands contained in the file. This is much more demanding and thus much slower than a function call.
Commands stored in a function are not executed in a subshell; they are executed in your current Shell. This is very similar to invoking a Shen program with the dot (.) command:
where the shell_pgm is some Shell procedure that you (or someone else) have created. if you recall, this command tells the Shell to execute the command in your current Shell environment. This is different from invoking the Shell directly, which causes the commands to run in a subshell. Since functions are executed in your current Shell, any changes to the environment performed in the function are permanently made to the current Shell. Upon return from the function execution, the changes made to the environment remain intact. Most important, the following changes remain in effect after return from the function call:
1. Any changes to any variables. This means setting of variables, unsetting, and exporting. Basically, any changes to any variables are permanent.
2. Any changes to the current directory remain in effect.
3. Any files used are also shared.
So use care when you execute a function call. it does behave differently from a normal Shell program call.
The commands in the function are executed until either the end of the function is reached, or an exit or return statement is encountered. if an exit statement is coded in your function, then both the function and the invoking Shell are exited. (We have seen previous examples of the exit command.) The return statement is a way to exit just the function with the option of returning some particular value. The syntax of the return statement is: return n, where n is an integer value that you would like returned as an exit status to the calling Shell. This value can be tested for using the $? variable to check to see what action the function performed. Did it complete properly or does some other action need to be taken? The return statement provides the ability to leave a function whenever you choose. For example, if some error condition occurs you can return from the function and inform the calling Shell program that some problem has occurred. If you do not supply a return statement and the end of the function is reached, then an implied return is performed with the exit status equal to the exit status of the last command performed in the function. This is also true if you provide a return statement with no value for n. The last executed command provides the return code. After completion of the function you are returned to the spot where the function was called from. If this was the command line, then you are returned to the command line. If the function was executed from within a Shell program, then a return starts execution at the line following the function call in the program.
If your function has an error when processing under the Bourne Shell, then the function and its calling Shell are exited.
Passing Arguments to Functions
Arguments are passed to functions in the same manner as any other Shell procedure. Simply type the arguments following the command name, in the normal fashion, and the function will be able to access these arguments in the variables $1 ... $9 in the case of the Bourne Shell. Of course, the Korn and Bash Shells can access variables beyond $9, as was discussed previously.
There is one small anomaly that you should take note of. When you call a function with arguments from inside a Shell program, the function arguments replace the arguments originally passed to the Shell program. of course, the solution to this problem is to store the arguments in a variable before you make the call to the function and then, upon return, replace the arguments if there is a need to do so. This can be done using the set command.
Another related approach is to parse all the arguments prior to any function calls and store any arguments in your own variables. The nice thing about this approach is that you can assign arguments to variable names that have more meaning than $1, $2, and so forth. When your programs start to get large and filled with numerous function calls and calls to other Shell programs, it is easy to lose track of what is being stored in the special variables $1 through $9. Good variable names are a key to easy understanding and maintenance of any program. Even though this approach is preferable, it may not always be possible. in those cases, the first approach of storing the arguments and then restoring them ran always be used.
Functions declarations have rules about where the functions themselves are applicable and what variables are accessible to the functions while they are executing. These rules are referred to as scoping rules.
When using the Bourne Shell, function declarations are local to the Shell in which they are defined. This means that any Shell program that runs in a subshell will not have access to the functions that were defined in the parent calling Shell process. in other words it is not possible in the Bourne Shell to export functions to make them available to called Shell procedures.
Once a function begins executing, there is the issue of which variables are available to the function. Since functions run in the current Shell, all variables defined in the current Shell procedure are available to all the functions declared in that Shell process. Also, any arguments passed to the function are available to the function in the special variables $1..$n as was mentioned before. Also, any variables defined in the function itself become available to the calling Shell procedure as well as to all other functions which may be called. Variables that participate in this kind of global sharing are called global variables. They are shared globally between all functions and procedures. By exporting a variable you make it global not only to functions but also to any Shell programs that run in a subshell.
When using the Bourne Shell, all traps are shared between the calling Shell program and the function. Thus, if a trap is reset in a function, it is reset for the calling Shell as well. The exit trap (signal 0) is not activated in the Bourne Shell when a function returns. This is not entirely true for the Korn Shell....
SHELL FOR THE NOVICE.
The Power of Shell.
Shell Decisions and Repetitions.
SHELL PROGRAMMING FOR THE USER.
User Shell Programming.
Structuring Shell Programs.
Internet and the Shell.
SHELL PROGRAMMING FOR THE POWER USER.
Rapid Prototyping and Reuse.
Shell for Programmers.
The Shell Innovator.
The UNIX System Administrator.