Some developers will use Bash to achieve very complex functions, like using other high-level language. He may feel that he is very fast hardware but others long to hammer burst him, Bash readability and maintainability is far lower than any high-level language. Even worse, Bash is not convenient debugging tools and proofing mechanism, you need to troubleshoot a problem for a long time.
In high-level languages such as Ruby or Python, you can easily know what is wrong what type of error lines, as well as the IDE Debugger blessing. The Bash can only see the source code, debugging through a very inefficient way to print log and so on.
This article will introduce Bash in set -euxo pipefail, they can help you write easier to maintain and more secure script. This is the ultimate Bash script debugging tools, and I hope you will add in your own scripts in such a line, but also less bald head a little.
set -e
set -eOption allows you to immediately withdraw from the script when an exception occurs, subsequent commands are no longer executed. By default, when Shell script does not end the execution because of an error, but in most cases, we hope that an exception would not have gone down. If your ifjudgment will appear in abnormal condition, then the script will exit, but perhaps this is not the situation you expect, then you can add in a statement after the judgment || trueto prevent exit.
Before
#!/bin/bash
# 'foo' is a non-existing command
foo
echo "bar"
# output
# ------
# line 4: foo: command not found
# barAfter
#!/bin/bash
set -e
# 'foo' is a non-existing command
foo
echo "bar"
# output
# ------
# line 5: foo: command not foundExamples prevent immediate withdrawal.
#!/bin/bash
set -e
# 'foo' is a non-existing command
foo || true
echo "bar"
# output
# ------
# line 5: foo: command not found
# barset -o pipefail
Bash will only check the default pipeline (pipeline) operation for the final return value of the command, if the rightmost command is successful then it is considered that the statement is no problem. This behavior is actually very safe, so there set -o pipefail. This represents a particular option in a command pipeline connected, as long as there is any command fails (return value is not 0), the entire pipeline operation is considered a failure. Only the pipeline all commands are executed successfully execute this pipeline to be successful.
Before
#!/bin/bash
set -e
# 'foo' is a non-existing command
foo | echo "a"
echo "bar"
# output
# ------
# a
# line 5: foo: command not found
# barAfter
#!/bin/bash
set -eo pipefail
# 'foo' is a non-existing command
foo | echo "a"
echo "bar"
# output
# ------
# a
# line 5: foo: command not foundset -u
set -uEasier to understand, Bash will all undefined variables as errors. Bash undefined variables will be considered empty by default, does not complain, and this is the source of many of the pit. Perhaps because of the nuances of variable names let you search for a long time and finally swearing.
Before
#!/bin/bash
set -eo pipefail
echo $a
echo "bar"
# output
# ------
#
# barAfter
#!/bin/bash
set -euo pipefail
echo $a
echo "bar"
# output
# ------
# line 5: a: unbound variableset -x
set -xBash allows each command before executing the first print, you may think this is the Bash Debug switch. It is of course obvious benefits, allowing you to quickly find the location of the script in question, but it also has disadvantages, that would be particularly Bash's log of chaos. In addition, it will command before printing variable to parse out, so you can know what the variable value statement currently executing Yes. Even log may be some chaos, messy hair is better than some good, it is recommended that this switch is still open.
#!/bin/bash
set -euxo pipefail
a=5
echo $a
echo "bar"
# output
# ------
# + a=5
# + echo 5
# 5
# + echo bar
# barAbove is about the set -euxo pipefailintroduction of writing from the perspective of Shell script Look, I highly encourage everyone should own Shell scripts add such a line. But the actual situation, if you Shell script has more than 200 lines, I suggest you replace the high-level language. Such as Python or Ruby or even Perl, these high-level language in Linux systems are built, note the version compatibility is good, than to write Shell uncomfortable too much.
About the Author:
Toby Qin, Python technology enthusiasts, currently engaged in test development related work, please indicate the original source.
Welcome attention to my blog https://betacat.online, you can go to my number to go public when the melons for the masses .
