Shell code specification

Shell code specifications-general Linux technology-Linux programming and kernel information. The following is a detailed description. Author: cactus

I have prepared a document based on my actual work and I will share it with you. It also provides some reference for other Linux development, although the article is poor. :)

1 Overview
1.1 Purpose
Defines Shell script naming and coding specifications, and serves as a technical reference for OS cropping design, development, and maintenance personnel.

1.2 Overview
Based on the features of Fedora Core 4.0, this article describes the coding specifications for installation scripts, OS initial scripts, and patch creation.

1.3 Development Tools
Shell scripts are files without development environments. In the FC4 graphic environment, gedit, vi, vim, and joe are available. We recommend that you use gedit and set the environment to sh for highlighted display; on the Character interface, you can use vi, joe, and vim, and ultraedit in Windows. The Shell script file with a Chinese character prompt is saved. The character encoding must be GB18030, GBK, or GB2132.

2. object naming rules
2.1 naming conventions
1. The naming conventions in this document are system configuration files and script files;

2. The file name, variable name, and function name cannot exceed 20 characters;

3. Only English letters, numbers, and underscores can be used for naming. Only one English word can be used for full spelling. When there are multiple words, they can be connected with underscores. The length is long and the first 3 ~ 4 letters. In case of complicated situations, we will discuss and decide together;

4. All file names are named in lower case and cannot be used in combination. (when a file is exchanged through a USB flash drive, the case may be lost, that is, all file names in upper case may be changed to lower case files );

5. Avoid using Linux reserved words such as true and keywords such as PWD (see the appendix );

6. Filter blank lines and comments when exporting configurations from the configuration file.

2.2 Shell script naming and specifications
The Shell script file contains the following files:

1. Linux Startup initialization files, such as/etc/rc. d/rc. sysinit

2. Hide the initialization file, such ~ /. Bash_profile ,~ /. Xinitrc, etc.

3. User-Defined Shell files, such as/root/install/scripts/findtermtype. Sh

The name length of these files cannot exceed 20 characters. When the script command is too long, it is separated by "_", such as rdc09_tianjin.sh and inst_cp86.sh.

2.3 indent
Since Shell does not have a good editing environment, indentation should be one TAB per line. It is not recommended to use spaces for indentation.

2.4 page wide
Do not exceed 80 lines in each line. If the limit is exceeded, we recommend that you use "\", except for command lines with pipelines.

2.5 Environment Variables
Variable: all uppercase letters

Variable reference: all variables are referenced with variable names and double quotation marks, such as "$ TERMTYPE" or "$ {TERMTYPE}". If the variable type is numeric, It is not referenced, for example:

To export a variable from the configuration file, add an uppercase letter before the variable to identify the differences between the exported variable and the custom environment variable, for example:

The reference of variable values should start with $ as much as possible, such as $ (ls inst _ *. sh). Avoid using 'ls inst _*. Sh'

Cyclic control variables can be named as single letters, such as I and j. It can also be a more meaningful name, such as UserIndex.

Environment variables are defined at the beginning of the script.

Functions use a large number of files and are defined at the beginning of the file in the form of environment variables.

2.6 Functions
The function is stored as a noun, and the first letter of the second word must be capitalized, such as updateConfig ()

Each function is controlled in 50-rows. If the number of rows exceeds the limit, two functions are recommended.

2.7 statement
If statement

The most likely part of the if/then/else statement to be executed should be placed in the then clause, and the less likely part to be executed should be placed in the else clause.

If possible, do not use a series of if statements instead of case statements.

Do not make the if statement nested more than five layers. Try to replace it with clearer code.

Case statement

Summary

A single clause in a case statement should be arranged in the numerical or alphabetic order of the case constant. The execution statement in the clause should be as simple as possible, generally no more than 4 to 5 lines of code. If the execution statement is too complex, place it in an independent function.

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

Format

The case statement follows the same indentation and naming conventions.

While statement

It is not good to Exit the while loop using the Exit process. If possible, use the loop condition only to end the loop.

All initialization code of the while loop should be kept close before entering the while loop, and should not be separated by other irrelevant statements.

Processing after the loop ends should follow the loop.

For statement

If you need to execute an incremental loop with a definite number of times, replace the while statement with the for statement.

2.8 signal capture
If you want to modify important configurations, capture the user's buttons. If you press Ctrl + C and other important operations to terminate the program, call the rollback program, for example:

2.9 comments
The program header should be annotated with the version and function description. However, the first line of the program cannot contain Chinese characters.

The program body should contain necessary notes, which are described as follows:

Single line comment, which can be placed at the end of the code line or at the top of the code line;

Multi-line comments are used to annotate complex Functional Descriptions. They can be placed in the program body or at the beginning of a code block.

When you modify the code, add necessary version notes and function instructions to the modified content. The format is as follows:

Annotations that are no longer useful must be deleted.