Here Document Few Tips

6. The evaluation of the arithmetic expressions of the form expression. Remember that the double−quoted expressions are processed differently from others after this step. 7. The eventual expanded text as a result of the previous step processing is now tokenized according to the shell environment internal field separators IFS. 8. The wildcard expansion of , ? and [] pairs, and processing of regular expression operators. 9. The search for the command in all predefined command directories according to the shell PATH or path variable. This is also the second, and the only, step in processing single−quoted command−line tokens. 10. At this point everything is ready for the command−line execution. However, if the shell command eval was specified, another round of the command processing will be performed. This is known as double command−line scanning. The format of the command is: eval args where args includes the actual command itself and command arguments. For better understanding of this command, see the following example. The users shell is bash, but it does not have any specific impact on the example could be any other shell. bash VAR1=VAR2 Define variable VAR1 bash VAR2=Example Define variable VAR2 bash echo VAR1 Check the values of variables VAR2 bash echo VAR2 Example bash eval echo VAR1 Check the values of variables upon double scanning Example bash eval echo VAR2 Example

3.5.2.4 Here Document

An extremely powerful feature of the shell programming is its Here Document. The shell redirector of the form: label forces the input to the specified command to be the shells standard input, which is read until the line that contains only label is reached. It means that all script command−lines within the Here Document will not be processed by the shell command interpreter. Instead they will be processed by the command specified at the start of the Here Document. Here is an example: myprogram EOF mycommandA mycommandB mycommandC EOF This shell script command−line sequence will start the execution and transfer the further command−line control to myprogram. Command lines that follow until the terminating label EOF are submitted to and strictly processed by myprogram. The specified label can be any string, but two labels must match literally; no leading or trailing blanks on the terminating line are allowed. 85 Here Document makes shell script programming easier and more powerful. For more details see the FTP example in Chapter 21.

3.5.2.5 Few Tips

At the end of this brief overview of certain shell programming topics, few tips for using the shell scripts: A shell script inherits the callers environment, usually the users shell. However there are no rules for the initial environment setting. Everything defined−out−of−script is uncertain, including the search path for the implemented commands in the script. Some good advice follows: Define the PATH variable in the script. ♦ Or, use the full−path command names. ♦ • It is very common that the fully tested shell script from the command line fails when it is run as a cron job. The reason is simple: cron environment is reduced to several default values, usually insufficient for the successful script execution. • Always clean everything that the shell script creates temporarily. Each file is owned by its creator, and remaining temporary files could be obstacle for other script invokers. • Pay attention to the standard and error output. The shell scripts are often running in background either. • 86

Chapter 4: System Startup and Shutdown

4.1 Introductory Notes

UNIX systems run continuously under normal circumstances. Shutting down and powering−off a UNIX system should be done rarely, usually only when a hardware upgrade is being performed or a system is being allocated, or occasionally when another action requiring a system shutdown is performed. In real life, system shutdown is more frequent, because unpredictable situations always occur. Power−cycling a UNIX system is not the only way the system can be shut down. Rebooting is also a familiar task for any UNIX administrator; UNIX administrators know well how system rebooting can be healthy for overall system maintenance. Nevertheless, keeping the UNIX system running is the most visible task of a system administrator. If the system crashes, everyone will complain, your phone will ring constantly, and you will find yourself anxiously trying to fix the problem and bring the system back into production. Quickly you will learn how important the system you are in charge of really is, and how many users depend on it. Even more important, you will learn how crucial a smooth, fast, proper system startup can be. This chapter covers topics related to normal UNIX system startup and shutdown procedures. Invoking a system startup and shutdown is quite simple; the main requirement is to be the superuser on the system an easy task for an administrator. On the other hand, making the system behave correctly, especially during startup, requires a great deal of knowledge and administrative skill. Proper system startup is supposed to customize and set the myriad of existing system configuration files that will control each portion of the UNIX system. Some of these files include system−related configuration data, but there are also site−added applications; the bottom line is that the system should be fully operational after any system startup. Given the complexity of properly configuring the system startup, this chapter could easily be located at the end of the overall text, rather than at its beginning. However, discussing the administration of a running UNIX system without knowing how that system came to be running seems strange; it is as though we are talking about administering a nonexistent UNIX system. So this material remains in the beginning by design; it will focus on the topic of global system startup and shutdown, and we will return to individual startup and shutdown issues later, whenever it is appropriate in discussing specific UNIX topics. From an administrative standpoint, system shutdown is the simpler procedure; at the end of the procedure a system must terminate all running processes, dismount all filesystems, and stop any other system activity. System shutdown works even if we never touch the default shutdown procedure — or perhaps it is better to say it mostly works, because the author of this text has witnessed a UNIX system that could not be shut down from the command line, and the only choice was to power−cycle the system. Our administrative task is to provide a graceful system shutdown. Everything must be stopped in a regular way, or the administrator will have to use the brute force method of power−cycling. System startup, on the other hand, must be done properly or the system will never come up. Obviously, more attention should be paid to system startup, and we will spend much more time discussing the startup procedure than the shutdown process. System startup is often referred to as system booting. Although booting specifies only one phase in the overall system startup, the two terms are commonly interchanged, as you will see in this chapter. Strictly speaking, system startup has a broader meaning than system booting. 87