Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Programming \ Writing Better Bash build script 8     - Oracle DataGuard principles and basic configuration (Database)

- Configuration OpenOCD + FT2232 under Ubuntu (Linux)

- Build your own Git server under Linux (Server)

- Linux kernel programming parameter passing between modules and function calls (Programming)

- Vmstat command Linux Performance Monitoring (Linux)

- Use Vagrant build cross-platform development environment for Python (Server)

- Five Linux user space debugging tool (Linux)

- MyCAT easy entry (Database)

- Linux operating system Study Notes (Linux)

- JavaScript subarray Deduplication (Programming)

- Linux, MySQL root privilege escalation another method (Linux)

- ActiveMQ-based shared file system HA solutions (Server)

- Archlinux installation tutorial (Linux)

- After installing minimize RHEL / CentOS 7 need to do some things (Linux)

- C ++: Postmodern systems programming language (Programming)

- Ubuntu 14.10 / 14.04 how to install Quick Start tool Mutate 2.2 (Linux)

- RHEL5 stalled due to power service error system can not start (Linux)

- Ubuntu deployed under regular tasks with crontab (Linux)

- Install the latest ATI / Nvidia graphics driver on Ubuntu (Linux)

- LVM mirrored logical volume to achieve (Linux)

 
         
  Writing Better Bash build script 8
     
  Add Date : 2018-11-21      
         
         
         
  When I started managing Linux and Unix servers, often you encounter a lot of other temporary administrator scripts written. Often because a script suddenly stop working and troubleshooting. Sometimes these norms have a good understanding of scripting, other times it is messy and confusing.

Although the investigation poorly written script a lot of trouble, but I have learned from that lesson. Even if you think that the script is only in use today, someone will go after the best two-year investigation also hold the attitude of scripting. Because there is always someone to view, and possibly even your own.

In this article, I would like to introduce some suggestions to optimize the script, not for the convenience of you write a script, but easy to figure out why people want the script does not work.

In the beginning of the release with the shebang line

Shell scripting is the first rule of interpretation with (shebang) at the beginning of the line. Although it sounds funny, but the release with the shebang line is very important, it tells the system which use binary as the script interpreter. No release with the shebang line, the system does not know which language to use interpreted scripting.

A typical bash to release with shebang line is as follows:

#! / Bin / bash
Other recommendations in this article is different, this is not just a suggestion, but a provision. shell script interpreter must begin with the line; there is no line, your script will eventually not work. I found that many script does not this line, some people do not think this line of script can not work, but it is not. If you do not specify a script interpreter, to explain some of the system will default to using / bin / sh directory. If bourne shell script, the default / bin / sh path is not the problem, or if it is KSH script instead of using a specific bash bourne, the script may produce unpredictable results.

 

Adding a script description header

When writing scripts or other programs at the beginning of the script I always describe the purpose of the script, while adding my name. If these scripts are written in the job, I will work together with mailbox and Scripting date.

Here is an example of script headers:

#! / Bin / bash
### Description: Adds users based on provided CSV file
### CSV file must use: as separator
### Uid: username: comment: group: addgroups: / home / dir: / usr / shell: passwdage: password
### Written by: Benjamin Cane - ben@example.com on 03-2012
Why add these? Very simple. Described here is to read the script to explain the script usage and provide other information they need to know. Add the name and e-mail, read the script person if you have questions you can contact me on and ask questions. Date added, when they read the script, at least know how long before the script is written. Date'll touch your nostalgia, when finding himself a long time ago to write the script, you'll ask yourself, "When writing the script, how I think?."

Script described head can be customized according to their own ideas, no hard and fast rules which are necessary and which do not. Generally as long as the information is valid and can be placed in the beginning of the script.


Indent your code

Code readability is very important, but a lot of people will ignore it. In-depth understanding of why it is important to indent before, we look at an example:

NEW_UID = $ (echo $ x | cut-d: -f1)
NEW_USER = $ (echo $ x | cut-d: -f2)
NEW_COMMENT = $ (echo $ x | cut-d: -f3)
NEW_GROUP = $ (echo $ x | cut-d: -f4)
NEW_ADDGROUP = $ (echo $ x | cut-d: -f5)
NEW_HOMEDIR = $ (echo $ x | cut-d: -f6)
NEW_SHELL = $ (echo $ x | cut-d: -f7)
NEW_CHAGE = $ (echo $ x | cut-d: -f8)
NEW_PASS = $ (echo $ x | cut-d: -f9)
PASSCHK = $ (grep-c ": $ NEW_UID:" / etc / passwd)
if [$ PASSCHK -ge 1]
then
echo "UID: $ NEW_UID seems to exist check / etc / passwd"
else
useradd-u $ NEW_UID -c "$ NEW_COMMENT" -md $ NEW_HOMEDIR -s $ NEW_SHELL -g $ NEW_GROUP -G $ NEW_ADDGROUP $ NEW_USER
if [-! z $ NEW_PASS]
then
echo $ NEW_PASS | passwd - stdin $ NEW_USER
chage -M $ NEW_CHAGE $ NEW_USER
chage -d 0 $ NEW_USER
fi
fi
The above code work? Yes, but this code is not written well, if this is a 500-line bash script, no indentation, then to understand the purpose of this script will be very difficult. The following look at the use of indentation after the same piece of code:

NEW_UID = $ (echo $ x | cut-d: -f1)
NEW_USER = $ (echo $ x | cut-d: -f2)
NEW_COMMENT = $ (echo $ x | cut-d: -f3)
NEW_GROUP = $ (echo $ x | cut-d: -f4)
NEW_ADDGROUP = $ (echo $ x | cut-d: -f5)
NEW_HOMEDIR = $ (echo $ x | cut-d: -f6)
NEW_SHELL = $ (echo $ x | cut-d: -f7)
NEW_CHAGE = $ (echo $ x | cut-d: -f8)
NEW_PASS = $ (echo $ x | cut-d: -f9)
PASSCHK = $ (grep-c ": $ NEW_UID:" / etc / passwd)
if [$ PASSCHK -ge 1]
then
echo "UID: $ NEW_UID seems to exist check / etc / passwd"
else
useradd-u $ NEW_UID -c "$ NEW_COMMENT" -md $ NEW_HOMEDIR -s $ NEW_SHELL -g $ NEW_GROUP -G $ NEW_ADDGROUP $ NEW_USER
if [-! z $ NEW_PASS]
then
echo $ NEW_PASS | passwd - stdin $ NEW_USER
chage -M $ NEW_CHAGE $ NEW_USER
chage -d 0 $ NEW_USER
fi
fi
After indentation, it is clear if the second statement embedded in the first if statement, but if we look not indented, certainly can not find it at first glance.

Indentation depends on your own, is to use two spaces, four spaces, or a tab on the use, it is not important. It is important in the same way every time the code is consistent indentation.


Increase spacing

Indent can increase the intelligibility of the code, and spacing can increase the readability of the code. Usually, I like to use the code according to the code interval, this is a personal preference, and its significance is to make the code more readable and easier to understand.

The following are examples of the code to add line spacing after:

NEW_UID = $ (echo $ x | cut-d: -f1)
NEW_USER = $ (echo $ x | cut-d: -f2)
NEW_COMMENT = $ (echo $ x | cut-d: -f3)
NEW_GROUP = $ (echo $ x | cut-d: -f4)
NEW_ADDGROUP = $ (echo $ x | cut-d: -f5)
NEW_HOMEDIR = $ (echo $ x | cut-d: -f6)
NEW_SHELL = $ (echo $ x | cut-d: -f7)
NEW_CHAGE = $ (echo $ x | cut-d: -f8)
NEW_PASS = $ (echo $ x | cut-d: -f9)
PASSCHK = $ (grep-c ": $ NEW_UID:" / etc / passwd)
if [$ PASSCHK -ge 1]
then
echo "UID: $ NEW_UID seems to exist check / etc / passwd"
else
useradd-u $ NEW_UID -c "$ NEW_COMMENT" -md $ NEW_HOMEDIR -s $ NEW_SHELL -g $ NEW_GROUP -G $ NEW_ADDGROUP $ NEW_USER
if [-! z $ NEW_PASS]
then
echo $ NEW_PASS | passwd - stdin $ NEW_USER
chage -M $ NEW_CHAGE $ NEW_USER
chage -d 0 $ NEW_USER
fi
fi
As you can see, line spacing, although imperceptible, but are so clean after every code debugging easier.

Commented code

Described head adapted to add a script function descriptions, and code comments to explain what the code for their own purposes. Here it is still the same as above the snippet, but this time I will add code comments, explain the purpose of the code:

### Parse $ x (the csv data) and put the individual fields into variables
NEW_UID = $ (echo $ x | cut-d: -f1)
NEW_USER = $ (echo $ x | cut-d: -f2)
NEW_COMMENT = $ (echo $ x | cut-d: -f3)
NEW_GROUP = $ (echo $ x | cut-d: -f4)
NEW_ADDGROUP = $ (echo $ x | cut-d: -f5)
NEW_HOMEDIR = $ (echo $ x | cut-d: -f6)
NEW_SHELL = $ (echo $ x | cut-d: -f7)
NEW_CHAGE = $ (echo $ x | cut-d: -f8)
NEW_PASS = $ (echo $ x | cut-d: -f9)
### Check if the new userid already exists in / etc / passwd
PASSCHK = $ (grep-c ": $ NEW_UID:" / etc / passwd)
if [$ PASSCHK -ge 1]
then
### If it does, skip
echo "UID: $ NEW_UID seems to exist check / etc / passwd"
else
### If not add the user
useradd-u $ NEW_UID -c "$ NEW_COMMENT" -md $ NEW_HOMEDIR -s $ NEW_SHELL -g $ NEW_GROUP -G $ NEW_ADDGROUP $ NEW_USER
### Check if new_pass is empty or not
if [-! z $ NEW_PASS]
then
### If not empty set the password and pass expiry
echo $ NEW_PASS | passwd - stdin $ NEW_USER
chage -M $ NEW_CHAGE $ NEW_USER
chage -d 0 $ NEW_USER
fi
fi
If you happen to read this bash code, but do not know the purpose of this code, you can at least view the comments fully grasp the realization of the object code. Add comments in the code is very helpful to others, even to yourself can also help. I have found myself in a browser script written a month ago did not know the use of the script. If you add comments reasonable, it can save a lot of your time and theirs in the future.


Create descriptive variable names

Descriptive variable names are very intuitive, but I found myself always use a common variable name. Often these are temporary variables, never used outside the block of code, but even temporary variables, explain their meaning is also useful.

The following examples of variable names mostly descriptive:

for x in`cat $ 1`
do
NEW_UID = $ (echo $ x | cut-d: -f1)
NEW_USER = $ (echo $ x | cut-d: -f2)
You may be assigned a value $ NEW_UID and $ NEW_USER is not very clear, what represents the $ 1 and $ x is the value of anything is not clear enough. More descriptive modify the code as follows:

INPUT_FILE = $ 1
for CSV_LINE in`cat $ INPUT_FILE`
do
NEW_UID = $ (echo $ CSV_LINE | cut-d: -f1)
NEW_USER = $ (echo $ CSV_LINE | cut-d: -f2)
From this rewrite code blocks, it is easy to see that we are reading an input file, the file name is a CSV file. At the same time it is easy to see that we get a new UID and new USER to store information from somewhere in the $ NEW_UID and $ NEW_USER variable.

The example above looks a bit overkill, but someone in the future will thank you to spend extra time to get more descriptive variables.


Use $ (command) command substitution

If you want to create a variable whose value is the output of another command, there are two ways in bash. The first is a command enclosed in backquotes, as follows:

DATE = `date +% F`
The second is to use a different syntax:

DATE = $ (date +% F)
Although both are correct, but I personally prefer the second method. This is purely a personal preference, but I usually think $ (command) syntax is more obvious than the use of anti-quotation marks. If you dig hundreds of lines of code bash; you will find yourself constantly with reading, those backticks sometimes looks like a single quote. Also, sometimes it looks like a single quote backticks. Finally, all the recommendations are linked to preferences. Therefore, the most suitable for you, make sure your choice is consistent with the method used.


Before exiting the error description of the problem

Above example makes the code easier to read and understand, the last piece of advice to find the error before the debugging process can be very useful. Add descriptive error message in the script, you can save a lot of time in the early debugging. Browse the code below to see how to make it more descriptive:

if [-d $ FILE_PATH]
then
for FILE in $ (ls $ FILE_PATH / *)
do
echo "This is a file: $ FILE"
done
else
exit 1
fi
The script first checks whether the value of $ FILE_PATH variable is a directory, if not, the script will exit and return an error code 1. Although the use of other scripts exit code can tell the script to execute successfully, but did not give the person running the script to explain.

We make the code more friendlier:

if [-d $ FILE_PATH]
then
for FILE in $ (ls $ FILE_PATH / *)
do
echo "This is a file: $ FILE"
done
else
echo "exiting ... provided file path does not exist or is not a directory"
exit 1
fi
If the first code snippet running, you will get a lot of output. If you do not get the output, you will have to open the script file to see what can go wrong. But if you run a second snippets, and you'll know you specify an invalid path to the script. Add only one line of code to save a lot of debugging time later.

I tried the above example is only used when the programming skills. I believe that write clean readable bash script There are many other good suggestions, if you have any suggestions, feel free to reply in the comments area. Very pleased to see that other people put forward skills.
     
         
         
         
  More:      
 
- See how --nand flash timing diagram of a read operation Comments (Programming)
- Ubuntu users install the Download Manager software Xdman 5.0 (Linux)
- Docker + Nginx + Tomcat7 simple load balancing configuration (Server)
- HA-Federation-HDFS + Yarn cluster deployment (Server)
- Ubuntu 14.10 used ifconfig commands to manage your network configuration (Linux)
- Linux / CentOS 7.0 installation and configuration under Tomcat 8.0 (Server)
- Udev: Device Manager for Linux Fundamentals (Linux)
- SSH security note (Linux)
- How to install new fonts on Ubuntu 14.04 and 14.10 (Linux)
- Oracle utilized undo data recovery operations (Database)
- Linux daemon (Linux)
- extundelete: the Linux-based open source data recovery tools (Linux)
- Learning C language pointer essays (Programming)
- The multiplexed signal driving IO (Programming)
- Use Tmux and Vim to make IDE (Linux)
- Jump table (skiplist) of code (Programming)
- C ++ 11 feature: decltype keywords (Programming)
- How to statistical data of various size Redis (Database)
- Installation Android IDE development tools, Android Studio 1.5 under Ubuntu (Linux)
- No password on Oracle and MySQL login (Database)
     
           
     
  CopyRight 2002-2022 newfreesoft.com, All Rights Reserved.