10 Best Practices for shell script Programming

Every programmer working on Unix/Linux may be good at shell script programming. However, the methods for solving problems vary, depending on the degree of professional knowledge, the types of commands used, and the way you view problems. For programmers at the initial stage of shell script programming, following appropriate practices can help you learn these programming skills faster and better. Next, let's discuss the methods that can help you learn shell script programming.1. More hands-on

You want to learn shell script programming, which is good. So you started learning with a book. Some people will first read the entire teaching material and then practice on the computer. This method may apply to some people, but I am not very optimistic about it. My suggestion is that you only need to learn some basic information that can help you start coding. Then, write some simple programs. Once you have to stop because of your lack of knowledge, go back to the book to read the part you want to know and continue to do your project. Continue to improve your level. I have benefited a lot from this method.

2. Make good use of the command prompt

Sometimes there are some errors in the script we write. We modified the error and run the script, but the system reported an error again. This error may occur many times. In such cases, you must first find the problematic line or command, which can be easily achieved through some debugging statements. Once this statement is found, try to execute the same statement at the command prompt. If it starts to run normally at the command prompt, you can easily infer the reason why it cannot run normally. It may be because of wrong commands, environment variables, or a binary file is referenced from different places. This method makes debugging easy.

3. Comprehensive Consideration

Now let's look at a question. You have come up with a solution for a problem, but this solution only applies to processing small files. But what should you do when processing large files? For example, we want to get the first line of the file: Code

1. Sed-N '1p' File

This statement will certainly give the first line of content you want. But what if the processed file contains millions of records? Although the SED command above can output the first line of the file, it will certainly cause performance problems to process large files.

Solution: Code

1. Sed-n'1p; 1q' File

This command outputs only the first line and exits the program.

4. Try different methods frequently.

You encountered a problem when writing a script, and then you found a unique solution. Next time you encounter a similar problem by accident, do not use the methods you used before. Try another method. If this problem occurs again one day, try other methods.
Example: Code

1. If [$? -EQ 0]
2. Then
3. Echo "success"
4. Fi

Another method: Code

1. [$? -EQ 0] & Echo "success"
   
   

5. Fast Coding

Scripts can save us time and increase productivity. However, do we spend less time writing scripts and testing? We want to write a script, So we open a file, write the code, save the file, run the script, and the system reports an error. Then we open the file to modify, save, and run the file ...... This process takes a lot of time. In this previous article entitled "How to quickly write shell scripts", you can learn how to write scripts and test scripts in the running state without review the command prompt. These methods can speed up encoding. When I write scripts, I always use these methods. And I can say with certainty that they have helped me save a lot of time.

6. frequent use of internal commands

In either case, consider using internal commands instead of external commands. In the previous article titled internal and external commands, we can see the differences between them. Using Internal commands will always benefit you. Based on the size of the input file being processed, internal commands can save a lot in terms of performance. Although you do not always have the opportunity to choose internal or external commands like this, in some cases, you can make the right choice.

7. There is no need to use Cat commands

This is one of the topics we often discuss in forums. There is no need to use the cat command. In some cases, we will find that there is no need to use the cat command. Sometimes, using excessive cat commands will make your code look ugly and cause performance problems.

Example: Code

1. $ CAT/etc/passwd | grep guru

The correct method should be: Code

1. $ Grep guru/etc/passwd

8. Read the error message carefully.

A common mistake for programmers is: when the command we typed reports an error, most of us only get a glimpse of the error message, instead of reading it carefully. In many cases, the error message contains a solution. More importantly, the system still reports an error after we modify an error and run it again. Then we modify it again, but the system reports an error again. This may take a long time. But in fact, the old error may have been corrected, but the system reports another error only because of some other new errors. We are still wondering why the modified Code still cannot run normally. Therefore, read the error message carefully.

9. Avoid bloated commands as much as possible

You are trying to filter a piece of information from a large file. Next, you may write a lot of commands to implement this function. However, even if you get the correct result, the command you write is not good enough and obscure. Therefore, we should try to avoid this situation. The following is a good example of code optimization.

For example, search for a user name with a user ID of 502.

The following command is not good: Code

1. $ Grep 502/etc/passwd | cut-D:-F1

This command is not good enough: Code

1. $ Grep 502/etc/passwd | awk-F ":" '{print $1 }'

This is a good command: Code

1. $ Awk-F ":" '$3 == 502 {print $1}'/etc/passwd

As in the preceding example, you can use a simple awk command to complete the retrieval task.

10. Add comments

You have written a script. A week or two later, you open the script file again. If it is not commented in, it may take a lot of time for you to understand the code. Although the Code is written by ourselves, it will waste a lot of time. Scripts are used to save time, so we have no reason to waste time understanding these files to save time. Therefore, please develop the good habit of adding comments to the script. These annotations do not have to be detailed, so you can understand them.