面向系统管理员的 Bash 指南(2)

1012  2018-06-1122:34:44  ssh myhost

1013  2018-06-1122:34:55  vim.bashrc

这使我更容易浏览我的命令历史记录并找到我两天前用来建立到我家实验室的 SSH 连接(我一次又一次地忘记......)。

Bash 最佳实践

我将在编写 Bash 脚本时最好的(或者至少是好的,我不要求无所不知)11 项实践列出来。

11、 Bash 脚本可能变得复杂,不过注释也很方便。 如果你在考虑是否要添加注释,那就添加一个注释。 如果你在周末之后回来并且不得不花时间搞清楚你上周五想要做什么,那你是忘了添加注释。

10、 用花括号括起所有变量名,比如 ${myvariable}。 养成这个习惯可以使用 ${variable}_suffix 这种用法了,还能提高整个脚本的一致性。

9、 计算表达式时不要使用反引号;请改用 $() 语法。 所以使用:

for  filein $(ls);do

而不使用:

for  filein`ls`;do

前一个方式是可嵌套的,更易于阅读的,还能让一般的系统管理员群体感到满意。 不要使用反引号。

8、 一致性是好的。 选择一种风格并在整个脚本中坚持下去。 显然,我喜欢人们选择 $() 语法而不是反引号,并将其变量包在花括号中。 我更喜欢人们使用两个或四个空格而不是制表符来缩进,但即使你选择了错误的方式,也要一贯地错下去。

7、 为 Bash 脚本使用适当的释伴shebang(LCTT 译注:Shebang,也称为 Hashbang ,是一个由井号和叹号构成的字符序列 #! ,其出现在文本文件的第一行的前两个字符。 在文件中存在释伴的情况下,类 Unix 操作系统的程序载入器会分析释伴后的内容,将这些内容作为解释器指令,并调用该指令,并将载有释伴的文件路径作为该解释器的参数)。 因为我正在编写Bash脚本,只打算用 Bash 执行它们,所以我经常使用 #!/usr/bin/bash 作为我的释伴。 不要使用 #!/bin/sh 或 #!/usr/bin/sh。 你的脚本会被执行,但它会以兼容模式运行——可能会产生许多意外的副作用。 (当然,除非你想要兼容模式。)

6、 比较字符串时,在 if 语句中给变量加上引号是个好主意,因为如果你的变量是空的,Bash 会为这样的行抛出一个错误:

if[ ${myvar}=="foo"];then

echo"bar"

fi

对于这样的行,将判定为 false:

if["${myvar}"=="foo"];then

echo"bar"

fi

此外,如果你不确定变量的内容(例如,在解析用户输入时),请给变量加引号以防止解释某些特殊字符,并确保该变量被视为单个单词,即使它包含空格。

5、 我想这是一个品味问题,但我更喜欢使用双等号( == ),即使是比较 Bash 中的字符串。 这是一致性的问题,尽管对于字符串比较,只有一个等号会起作用,我的思维立即变为“单个 = 是一个赋值运算符!”

4、 使用适当的退出代码。 确保如果你的脚本无法执行某些操作,则会向用户显示已写好的失败消息(最好提供解决问题的方法)并发送非零退出代码:

# we have failed

echo"Process has failed to complete, you need to manually restart the whatchamacallit"

exit1

这样可以更容易地以编程方式从另一个脚本调用你的脚本并验证其成功完成。

3、 使用 Bash 的内置机制为变量提供合理的默认值,或者如果未定义你希望定义的变量,则抛出错误:

#this sets the value of $myvar to RedHat,and prints 'redhat'

echo ${myvar:=redhat}

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/4970460dfd400d7cd63ea3709eb525ad.html