The best practice for writing shell scripts is to standardize a

With the shell program more and more, found that each write has different habits or define different things, variable name definition is not the same, the entire program indentation is not uniform, no comments and other issues, and I looked back at these programs when I found it very troublesome. So I wrote a shell code specification.

1.1 Purpose

Define shell script naming and coding specifications, unified management of shell scripts, easy for themselves and others to view, improve code writing speed and aesthetics, temporarily only to restrict themselves, others only for reference.

1.2 Development tools

Shell script is a file, no development environment, FC4 graphics environment, can be used gedit, VI, VIM, Joe, etc., the recommended use of vim because of this most general, his function is also very powerful, if you want to use the Gvim in the graphical, and set the environment to SH highlighting, method : 1) CP/ETC/VIM/VIMRC ~/.VIMRC 2) Vim ~/.VIMRC Remove "syntax on, and under Windows, UltraEdit available. When the file is saved, the shell script file with the Chinese character hint must be one of the three gb18030/gbk/gb2132 (UTF-8) formats when the file is saved.

2 Object Naming Conventions

2.1 Naming conventions
1. The naming convention of this document is System configuration file, script file;

2. File name, variable name, function name not exceeding 20 characters;

3. The name can only use English letters, numbers and underscores, only one English word use full spelling, when there are multiple words, using underscores separated, long length, you can take the words before the four letters.

4. Filenames are all lowercase and cannot be mixed (when swapping files via USB drive, case may be lost, i.e. uppercase filenames may all become lowercase filenames);

5. Avoid using Linux for reserved words such as true, keywords such as PWD, etc. (see Schedule);

6. When exporting a configuration from a configuration file, be careful to filter empty lines and comments

2.2 Code Opening conventions

1, the first line is generally called the language used

2, the following to have this program name, to avoid changing the file name is unable to find the correct file

3. Version number

4, the time after the change

5. Relevant information of the author

6, the role of the procedure, and matters needing attention

7. Copyright and whether to open and share the GNU instructions

8, the final version of the update a brief description
As in the following example:

#!/bin/bash
# -------------------------------------------------------------------
# Filename:check_mem.sh
# revision:1.1
# DATE:2009/02/10
# Author:ajian
# email:ajian521#gmail.com
# Website:www.ohlinux.com
# Description:plugin to monitor the memory of the system
# Notes:this Plugin uses the "" command
# -------------------------------------------------------------------
# copyright:2009 (c) Ajian
# LICENSE:GPL
#
# is the free software; You can redistribute it and/or
# Modify it under the terms of the GNU general public License
# as published by the Free software Foundation; Either version 2
# of the License, or (at your option) any later version.
#
# distributed in the hope that it'll be useful,
# but without any WARRANTY; Without even the implied warranty
# of merchantability or FITNESS for A particular PURPOSE. See the
# GNU general public License for more details.
#
# You should has received a copy of the GNU general public License
# along with the (or with Nagios);
#
# Credits go to Ethan Galstad for coding Nagios
# If Any changes is made to this script, please mail me a copy of the changes
# -------------------------------------------------------------------
#Version 1.0
#The first one, can monitor the system memory
#Version 1.1
#Modify the method of the script, more fast

Because the shell does not have a good editing environment, it is recommended to use four spaces for the base indentation, the benefits of different environments tab may represent a different number of spaces, resulting in code confusion. The advantage of using tab is that it is fast and convenient, and can be used in the Editing tab, but it needs to be converted.

Can be changed in the editor, Windows does not say, mainly vim

: Set softtabstop=4

Be careful not to use: Set tabstop=4 above that is at the same time to convert this tab to four spaces, and this is the definition of tab four spaces, if you see the default 8 spaces on the other editor, it will be ugly.

In addition, the original tab is converted to a space: Retab

If you want to make the configuration permanent, you need to change the vim configuration file Vim ~/.VIMRC, more detailed and useful configuration See "Vim Configuration Summary"

2.4 Page width

Do not exceed 80 words per line, if exceeded, the proposed "" line, with the exception of a pipeline command line.

2.5 Environment variables

Variables: All uppercase letters

Variable references: All with the variable name plus double quotation marks, such as "$TERMTYPE", or "${termtype}" if the variable type is numeric type not referenced, such as:

If you need to export a variable from a configuration file, add an uppercase letter before the variable to identify the difference between the exported variable and the custom environment variable, such as:

The reference to a variable value should start with $, such as $ (LS inst_*.sh), avoiding the use of ' LS inst_*. Sh '

loop control variables can be named as a single letter, such as I, J, and so on. It can also be a more meaningful name, such as Userindex.

Environment variables and global variables are defined at the beginning of the script.

The function uses more files in the form of an environment variable defined at the beginning of the file, only the variables used in the function are defined at the beginning of the function

2.6 Functions

The function is stored in the form of a noun, and the first letter of the second word is capitalized, such as Updateconfig ()

Each function is controlled in 50-100 rows, and the number of rows exceeded is suggested to be divided into two functions

Programs that are called repeatedly are best divided into functions that simplify the program and make the program more organized.

2.7 statements

If statement

The most likely part of the If/then/else statement should be placed in the then clause, and the part that is unlikely to be executed should be placed in the ELSE clause.

If possible, try not to use a series of if statements instead of a case statement.

Do not nest the IF statement more than 5 layers and try to replace it with clearer code.

Case statement

Profile

A single clause in a case statement should be in the numeric order or alphabetical order of the case constants. The execution statements in the clause should be kept as simple as possible, typically no more than 4 to 5 lines of code. If the execution statement is too complex, it should be placed in a separate function.

The * clause of the case statement should be used only in the normal default case or when an error is detected.

Format

Case statements follow the same indentation and naming conventions.

While statement

It is not good to exit while loop using exit procedure; If possible, only loop conditions should be used to end the loop.

All initialization code for the while loop should be close to the while loop and not separated by other unrelated statements.

The processing at the end of the loop should immediately follow the loop.

For statement

If you need to perform an incremental loop of a certain number of times, you should replace the while statement with a for statement.

2.8 Signal Capture

If you make important configuration changes, you should capture the user keys, if the user presses CTRL + C and other important actions to terminate the program, call the fallback program, such as:

2.9 about annotations

The program header should be annotated with the version and function description. But the first line of the program is not kanji.

The necessary comments should be included in the body of the program, with the following notes:

A single-line comment that can be placed at the end of a line of code or at the top of a line;

Multi-line annotations for annotating complex functional descriptions, either in the program body or at the beginning of a block of code

When the code is modified, add the necessary version notes and function descriptions to the modified content.

The best practice for writing shell scripts is to standardize a