Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to analyze Linux Shell programming. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Many scripts are run as scheduled tasks rather than manually when they are actually used. However, scripts that implement the same function may encounter different problems in these two modes of operation.

Scripts that run as scheduled tasks often encounter the following problems.

Path problem: the current directory is often not the same as the script file. As a result, scripts cannot easily use relative paths when referencing external files they use, such as configuration files and other script files.

The command cannot find a problem: some external commands used in the script can be called normally when the script is executed manually. However, running under a scheduled task may have the problem that the script parser cannot find the relevant command.

Script repeat running problem: the execution of one script is not finished, and the next script has already started. Causes multiple processes in the system to run the same script at the same time.

Here are some ways to deal with the above common problems in the development of scheduled task scripts.

Path problem

Under scheduled tasks, the current path is often not the directory where the script file is located. So we need to refer to it with an absolute path. That is, first get the directory where the script is located, and then use the absolute path to reference the external files needed by the script on the basis of that directory. The method is shown in the following code.

Listing 1. Get the path where the script file is located, echo The script is located at: $scriptPath "cat" $scriptPath/readme "# use absolute path to reference external files

Place the script in listing 1 under the directory / opt/demo/scripts/auto-task and add the script to cron. The output of the scheduled task run is as follows.

Current path is: / home/viscent

The script is located at: / opt/demo/scripts/auto-task

The command could not find the problem

Scripts running under scheduled tasks may have the problem that the script parser cannot find the relevant commands. For example, the sqlplus command in the Oracle database. If the script calls the command without special processing, executing it under a scheduled task will prevent the script parser from finding the command. An error message like the following appears:

Sqlplus: command not found

This is because when the script is executed under a scheduled task, the script is executed by a non-login Shell, and the parent Shell of the execution script is not the Shell of the Oracle user. Therefore, the. profile file of the Oracle user is not called at this time. So the solution is to add the following code at the beginning of the script:

Listing 2. Resolve the problem that external commands cannot be found 1source / home/oracle/.profile

That is, problems where external commands cannot be found can be solved by adding a statement in the. profile file of the source user at the beginning of the script.

The problem of running the script repeatedly

Another common problem with scheduled task scripts is the repetition of scripts. For example, a script is set to run every 5 minutes. If a run of the script cannot be finished within 5 minutes, the scheduled task service will still start a new process to execute the script. At this point, multiple processes running the same script appear. This can lead to script dysfunction. And wasting system resources. There are usually two ways to avoid repeated runs of scripts. One is to check whether there are other processes running the script on the system when the script is executed. If present, the current script is terminated. Second, when the script runs, it checks whether there are other processes in the system that are running the script. If it exists, end that process (this method has some risks, so use it carefully! ). Both methods need to check at the beginning of the script whether a process running the current script already exists on the system, and if so, get the PID of that process. The sample code is shown in listing 3 below.

Listing 3. Method to prevent script from running repeatedly: 112345678910111213141516171819202122232425272829303132 The script already running () {selfPID= "$" scriptFile= "$0" typeset existingPidexistingPid= `getExistingPIDs $selfPID "$scriptFile" `if [!-z "$existingPid"]; then echo "The script already running, exiting..." Exit-1fidoItsTask} # get the PIDgetExistingPIDs () {selfPID= "$1" scriptFile= "$2" ps-ef | grep "/ usr/bin/ksh ${scriptFile}" | grep-v "grep" | awk "{if (\ $2 efficient script selfpid) print\ 2}" doItsTask () {echo "Task is now being executed..." sleep 20 # sleep for 20s to simulate tasks that take a long time to complete in the script. Listing 4. Method to prevent script from running repeatedly: 21234567891011121314151617181920212223252728293031 The script already running () {selfPID= "$" scriptFile= "$0" typeset existingPidexistingPid= `getExistingPIDs $selfPID "$scriptFile" `if [!-z "$existingPid"]; then echo "The script already running, killing it..." Kill-9 "$existingPid" # this method has certain risks, so use it carefully! FidoItsTask} # gets the PIDgetExistingPIDs () {selfPID= "$1" scriptFile= "$2" of the process running the current script other than its own

Ps-ef | grep "/ usr/bin/ksh ${scriptFile}" | grep-v "grep" | awk "{if (\ $2 thanks thanks selfpid) print\ $2}"

} doItsTask () {echo "Task is now being executed..." sleep 20 # Sleep 20s to simulate scripts performing tasks that take a long time to complete} main $* script debugging skills

Although a common problem in Shell development is the difficulty of debugging and the lack of effective debugging tools. However, we can take some ways of development and debugging that can help us avoid debugging difficulties to some extent. Because it is script development, many people are used to writing code line by line directly, and there is not even a function in a script. Although there is no grammatical and functional problem with this approach. But this increases the difficulty of debugging. On the contrary, if you write scripts in a modular way, it makes the code structure clear and easy to debug. At this point, we can look at such an example.

Suppose the function of the following script is to collect relevant log files in the production environment to locate the problem. The log files to be collected include the operating system log, the middleware log, and the log of the application system itself. These files will be compressed into a gz file.

Listing 5. Automatically collect the log file 12345678, collect the log file 12345678, package the three types of logs, make it easy to download} {collectSyslog # collect the system log file collectMiddlewareLog # collect the middleware log file collectAppLog # collect the application system log file tar-zcf logs.tgz syslog.zip mdwlog.zip applog.zip

If the script execution reports the following error:

Tar: applog.zip: Cannot stat: No such file or directory

We can lock down the collectAppLog function very quickly. Because it is responsible for outputting the applog.zip file. There is no need to look at the rest of the code.

Another benefit of adopting a modular approach is that the results of code debugging can be consolidated. For example, in the above example, if you have debugged the function that operates the status log collection. Next, when debugging other functions, the code being debugged may need to be changed. But it is unlikely that these changes will affect previously debugged code. On the contrary, if a script is full of statements without functions, the ability to collect all three kinds of logs may be affected by changing one line of code.

Another typical scenario is that during the scripting process, we may write some tentative code because we are not sure how to deal with some problems. Then, through repeated debugging to confirm the correct way of handling. In fact, this tentative code may be a statement or even a command. But many people repeatedly debug this small piece of code in a large piece of code. This will be very time-consuming. Especially when there are errors in other parts of the code during debugging, the author has to solve other errors first, otherwise the code we really want to debug may not be executed. In this case, write a small testable script.

Debugging in this script is not quite sure how to write the code and how to "integrate" it into the script we are developing. This can improve debugging efficiency and avoid consuming time that should not have been consumed. For example, during the writing process, we need to get the process ID of the process in which the script itself is located. At this point, we are not sure how to write the code that gets the id of the current process. So, we can create a new testable script in which we try to implement the function of getting the process ID. Once we find the right way, "port" the code to the script we really want to develop.

Handle long character output

One of the problems that you often have to deal with in script development is to output prompts. Of course, for short prompt output, the echo command is sufficient. However, it is not elegant to still use the echo command for large chunks of prompt output. A more appropriate approach is to use the cat command in conjunction with input redirection. Here is a concrete example to illustrate this point.

Suppose the following script installs a program to a user-specified directory. If the directory specified by the user does not exist, prompt

The user checks that the specified directory is correct and re-executes the script.

Listing 6. Use the echo command to output a large chunk of the character 12345678910111213 echo echo ERROR = "$1" if [!-d "$KSH"]; it is also necessary to handle the display of the special character echo'* * 'echo ERROR.

Echo "The destination directory not exists,make sure

Below directory you specified is correct: "

Echo ${path} echo "Then re-run this script." echo'* *'fi

The code is not very readable in this way, and the reader needs to read multiple echo commands and then "synthesize" to understand exactly what the prompt is. In addition, once the prompt message needs to be changed. This change may cause syntax errors due to the accidental addition of special characters such as double quotes when changing one of the echo commands, thus affecting the execution of the entire script.

The code in listing 7 shows how to use the cat command and input redirection to better handle the output of large chunks of text.

Listing 7. Use the cat command to output a large chunk of the character 1234567891011121314, "if if" = "$1" KSH path = "$1" KSH path =!-d "$KSH"] Thencat***ERRORThe destination directory not exists,make sure belowdirectory you specified is correct:$ {path} Then re-run this script.***EOFfi

Obviously, the code in this way is simpler and more readable. The reader only needs to read a command to know the specific content of the prompt message. And, to change the prompt, we can safely change the part between the two file Terminators EOF. Even if the modification is wrong, it will not affect the rest of the code.

Avoid using unnecessary temporary files

Novices often use temporary files when writing Shell scripts without the need for temporary files. Not only does this increase the amount of code writing (to handle creating, reading, and deleting temporary files, etc.), but it may also slow the script down (the file Iwhite O is not a fast operation after all).

The following example assumes that there is a script that adds the following line of text to all the. txt files in the current directory:

-End of file name-

Listing 8. And listing 9. The code in shows the code that uses the temporary file when it is not necessary and the code that does not need to use the temporary file.

Listing 8. Use temporary file 123456789101112131415161718192022324252627 when temporary file is not necessary. Txt | awk'{print $NF}'> tmp # redirect command output to temporary file tmpcat tmptypeset fileNametypeset lastLinewhile read fileName # read each line of do lastLine= `tail-1 "$fileName" `if [! $lastLine "="-- End of $fileName-- "] in the temporary file line by line Then echo "--End of $fileName--" > > $fileName fidonerm tmp # delete temporary file listing 9. Do not use the temporary file 12345678910111213141516171819. Instead of using the temporary file 12345678910111213141516171819, please use the ls-lt *. Txt | awk'{print $NF}') do lastLine= `tail-1 "$fileName" `if [! "$lastLine" = = "--End of $fileName--"]; then echo "--End of $fileName--" > > $fileName fidone use an editor that supports FTP

If your development environment is under the Windows operating system, and the testing is done on Linux through terminal software such as Putty. In this case, many developers are used to editing scripts directly on terminal software (such as using the vi command). Obviously, editing in this way is inefficient. Moreover, script development often needs to be tested while modifying. Even if it is a syntax error, due to the lack of tool support, we may have to run a script to find it. Therefore, improving the efficiency of script editing improves the efficiency of development to some extent. A good option to improve script editing efficiency when developing scripts on Windows systems is to use editors that support simple FTP features, such as Editplus and UltraEditor. You can use these editors to "open" (in effect download) the script file on the Linux test host in FTP. When the script is saved after editing, these editors automatically upload the script to the test host. The next step is to test the script through the terminal software. If you need to continue to modify the script after testing, you can take advantage of the editor's Reload document feature (which you can usually set shortcuts for).

The above is the editor for you to share how to parse Linux Shell programming, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.