Bash编程易犯的错误

文章由LinuxBoy分享于2019-03-25 12:03:54热评（608）

Bash编程易犯的错误

———————————华丽的分割线 begin———————

1. for i in $(ls *.mp3)

2. cp $file $target

3. 文件名中包含短横'-'

4. [ $foo = "bar" ]

5. cd $(dirname "$f")

6. [ "$foo" = bar && "$bar" = foo ]

7. [[ $foo > 7 ]]

8. grep foo bar | while read -r; do ((count++)); done

9. if [grep foo myfile]

10. if [bar="$foo"]; then ...

11. if [ [ a = b ] && [ c = d ] ]; then ...

12. read $foo

13. cat file | sed s/foo/bar/ > file

14. echo $foo

15. $foo=bar

16. foo = bar

17. echo <

18. su -c 'some command'

19. cd /foo; bar

20. [ bar == "$foo" ]

21. for i in {1..10}; do ./something &; done

22. cmd1 && cmd2 || cmd3

23. echo "Hello World!"

24. for arg in $*

25. function foo()

26. echo "~"

27. local varname=$(command)

28. export foo=~/bar

29. sed 's/$foo/good bye/'

30. tr [A-Z] [a-z]

31. ps ax | grep gedit

32. printf "$foo"

33. for i in {1..$n}

34. if [[ $foo = $bar ]]

35. if [[ $foo =~ 'some RE' ]]

36. [ -n $foo ] or [ -z $foo ]

37. [[ -e "$broken_symlink" ]] returns 1 even though $broken_symlink exists

38. ed file <<<"g/d\{0,3\}/s//e/g" fails

39. expr sub-string fails for "match"

40. On UTF-8 and Byte-Order Marks (BOM)

41. content=$(

42. somecmd 2>&1 >>logfile

43. cmd; (( ! $? )) || die

缩进准则

我一般使用2个空格来缩进（尽管大多人使用4个空格），原因是：

输入简单快速；

没有输入一个Tab键，避免不同环境下显示的差异问题；

缩进的效果已经足够，并且没有浪费太多的空间；

译者注：本人也是使用4个空格，如果你也与本文作者的风格不一样，下面说到2个空格的地方请自觉替换成你实际使用的空格数。个人认为，缩进只是一个个人的风格，只要不影响可读性即可。

顺便说一句，尽量不要使用Tab键，它们容易带来麻烦，我只能想到一种情况下它是有用的：here document中的缩进。

分隔长行

如果需要分隔过长的代码，你可以使用下面的任意一种方法：

1）使用与命令宽度相同的缩进

activate some_very_long_option \

some_other_option

2）使用2个空格缩进

activate some_very_long_option \

some_other_option

从个人的角度来说，除非有特别的需要，我更倾向于第一种形式，因为它突出“上下两行的内容是一起的”这一联系。

分离复合命令

译者注：其实这里的复合命令就是指块语句，例如for/while循环, if分支结构等等。

HEAD_KEYWORD parameters; BODY_BEGIN

BODY_COMMANDS

BODY_END

我习惯于：

将HEAD_KEYWORD和初始化命令或者参数放在第一行；

将BODY_BEGIN同样放在第一行；

复合命令中的BODY部分以2个空格缩进；

BODY_END部分独立一行放在最后；

1）if/then/elif/else分支语句

if ...; then

...

elif ...; then

...

else

...

2）for循环

for f in /etc/*; do

...

done

3） while/until循环

while [[ $answer != [YyNn] ]]; do ... done

4） case分支语句

case $input in

hello)

echo "You said hello"

;;

bye)

echo "You said bye"

if foo; then

bar

;;

echo "You said something weird..."

;;

esac

几点注意的地方：

如果不是100%需要，匹配部分左右的括号不需要写（译者注：例如写成hello)而不是(hello)）；

匹配模式与分支的终止符号;;位于同一缩进级别

分支内部的命令多缩进一层；

尽管是可选的，这里还是把最后一个分支的终止符号也写上了；

语法和编码指引

晦涩的语法结构

我们都喜欢一些晦涩的语法结构，因为它们很简洁。但是如果不是100%需要用到，尽量不要使用它们，否则大多数人无法理解你的代码。

所以有有时候，我们需要在代码的智能，效率与可读性之间找到一个平衡点。

如果你一定要使用这种语法结构，记得在用的地方写上一小段注释。

译者注：Shell提供的一些语法糖很难理解，但是有非常简洁实用，本人也很喜欢用，这样可以省下一大堆精力，而且用熟了也没有什么难以理解的，但是作者说的也有道理，这一点就仁者见仁，智者见智了

变量名

因为所有保留的变量名都是大写的，最安全的方法是仅使用小写字母作为变量名，例如读入用户的输入、循环变量等等……：

变量名尽量选择小写字母；

如果你使用大写的变量名，不要使用保留的变量名（一份不完全的列表参见SUS）；

如果你使用大写的变量名，最后在变量名前面加一个独特的前缀（例如下面例子中的MY_）；

下面是一个例子：

#!/bin/bash

# the prefix 'MY_'

MY_LOG_DIRECTORY=/var/adm/

for file in "$MY_LOG_DIRECTORY"/*; do

echo "Found Logfile: $file"

done

变量初始化

正如C语言一样，最好的处理是在变量声明的时候初始化。

用户可以将一个变量以环境变量的形式传递到脚本中。如果你盲目地假定你使用的所有变量都是未初始化的，其它人可以以环境变量的形式劫持一个变量。

译者注：一个例子说明这一点：

$ cat b.sh

if [ -z "$var" ]; then

echo "$var is not set"

var=1

echo "Now, var is equals to $var"

var=2 sh b.sh

Now, var is equals to 2

解决这个问题的方法很简单，将变量初始化：

my_input=""

my_array=()

my_number=0

参数展开

除非你知道自己做的事情，请在参数展开的地方使用双引号

当然，也有一些地方并不需要使用双引号，例如：

[[ ]]测试表达式内部是不会展开的；

在case $WORD in语法中WORD也不会展开的；

在变量赋值var=$WORD的地方也是不会展开的

但是在这些地方使用引号并不会出错，如果你习惯于在每个可能展开参数的地方使用引号，你写得代码会很安全。

如果你要传递一个参数作为一个单词列表，你可以不使用引号，例如：

list="one two three"

# you MUST NOT quote $list here

for word in $list; do

...

done

函数名称

函数名称应该采用小写的形式，并且有一个很好的意义。函数名称应该容易让人理解，比如f1这个名称虽然容易输入但是对调试和其它人阅读代码造成了很大的困难，它说明不了任何东西。好的函数名称可以帮助说明代码，而不需要额外的注释。

一个或多或少有趣的是：如果你无意这样做，不要把函数名称命名为常见的命令名，新手往往比较容易将脚本或者函数名命名成test，这样就和UNIX的test命令冲突了。

除非绝对必要，仅使用字母、数字和下划线作为函数名称。/bin/ls也是一个合法的Bash函数名称。

译者注：/bin/ls不是一个合法的函数名称。

命令替换

正如文章the article about command substitution [Bash Hackers Wiki]中提及的，你应该使用$( .. )形式。

不过，如果可移植性是一个问题，你可能必须使用反引号的形式`...`。

在任何情况，如果其它展开或者单词分隔并不是你期望的，你应该将命令替换用双引号引起来。

Eval命令

正如Greg据说的：“If eval is the answer, surely you are asking the wrong question.”。

避免它，除非绝对必要：

eval can be your neckshot（可能是你的麻烦？）

很有可能有其它的方法来实现你需要的；

如果可能，重新思考下脚本的工作过程，当eval的使用不可避免的时候；

如果你实在需要使用，小心慎用；

脚本的基本结构

一个脚本的基本结构是这样的：

#!SHEBANG CONFIGURATION_VARIABLES

FUNCTION_DEFINITIONS

MAIN_CODE

Shebang

如果可能，请不要忘记shebang。

请小心使用/bin/sh作为shebang，在Linux系统中，/bin/sh就是Bash这是一个错误的观点。

于我而言，shebang有两个目的：

说明直接执行时以哪个解释器来执行；

明确该脚本应该以哪个解释器来执行；

配置变量

在这里，我将这一类变量——可以被用户更改的——叫做配置变量。

让这类变量容易找到，一般放在脚本的头部，给它们有意义的名称并且加上注释说明。正如上面说的，仅当你知道你为什么这么做的时候，才用大写的变量名形式，否则小写形式更加安全。

函数定义

所有函数定义应该在脚本主要代码执行之前，这样可以给人全局的印象，并且确保所有函数在使用之前它是已知的。

你应该使用可移植性高的函数定义形式，即不带function关键字的形式。

脚本行为和健壮性

当脚本检测到问题时尽早退出，以免执行潜在的问题；

如果你需要用到的命令可能并没有安装在系统上，在脚本执行的时候最好检查命令是否存在并且提醒用户缺少什么；

采用有意义的脚本返回值，例如0代码成功，1代码错误或者失败；

其它

输出内容

if the script is interactive, if it works for you and if you think this is a nice feature, you can try to save the terminal content and restore it after execution；（译者注：不理解这一点是什么意思）

在屏幕中输出简单易理解的消息；

使用颜色或者特别的前缀区分错误和警告信息；

输出正常的内容到STDOUT，而输出错误、警告或者诊断的信息到STDERR；

在日志文件中输出所有详细的信息；

输入

不要盲目地假设任何事情，如果你希望用户输入一个数字，请在脚本中主动检查它是否真得是一个数字，检查头部是否包含0，等等。我们都应该知道这一点，用户仅仅是用户而不是程序员，他们会做他们想要的，而不是程序想要的。

——————————————————华丽的分割线 begin—————————————

1. for i in $(ls *.mp3)

Bash写循环代码的时候，确实比较容易犯下面的错误：

for i in $(ls *.mp3); do # 错误!

some command $i # 错误!

done

for i in $(ls) # 错误!

for i in `ls` # 错误!

for i in $(find . -type f) # 错误!

for i in `find . -type f` # 错误!

files=($(find . -type f)) # 错误!

for i in ${files[@]} # 错误!

使用命令展开时不带引号，其执行结果会使用IFS作为分隔符，拆分成参数传递给for循环处理；

不应该让脚本去解析ls命令的结果；

我们不能避免某些文件名中包含空格，Shell会对$(ls *.mp3)展开的结果会被做单词拆分(WordSplitting)的处理。假设有一个文件，名字为01 - Don't Eat the Yellow Snow.mp3，for循环处理的时候，会今次遍历文件名中的每个单词：01, -, Don't, Eat等等：

$ for i in $(ls *.mp3); do echo $i; done 01 - Don't

Eat

the

Yellow

Snow.mp3

比这更差的情况是，上面命令展开的结果可能被Shell进一步处理，比如文件名展开。比如，ls执行的结果中包含*号，按照通配符的规则, *号会被展开成当前目录下的所有文件:

$ touch "1*.mp3" "1.mp3" "11.mp3" "12.mp3"

$ for i in $(ls *.mp3); do echo $i; done

1*.mp3 1.mp3 11.mp3 12.mp3

1.mp3

11.mp3

12.mp3

1.mp3

11.mp3

12.mp3

不过，在这种场景下，你即使加上引号，也是无济于事的：

$ for i in "$(ls *.mp3)"; do echo --$i--; done

--1*.mp3 1.mp3 11.mp3 12.mp3--

加上引号后，ls执行的结果会被当成一个整体，所以for循环只会执行一次，达不到预期的效果。

事实上，这种情况下，根本不需要使用ls命令。ls命令的结果本身就设计成给人读的，而不是给脚本解析的。正确的处理方法是，直接使用文件名展开（通配符）的功能：

$ for i in *.mp3; do

> echo "$i"

> done

1*.mp3

1.mp3

11.mp3

12.mp3

文件名展开是位于各种展开（花括号展开、变量替换、命令展开等）功能中的最后一个环节，所以不会有之前不带引号的命令展开的副作用。如果你需要递归地处理文件，可以考虑使用Find命令。

到这一步，之间的问题看样子已经修复了。但是，如果你进一步思考，假设当前目录上没有文件时会怎么样？没有文件的时候，*.mp3不会被展开直接传递给for循环处理，所以这个时候循环还是会执行一次。这种情况不是我们预期的行为。保险起见，可以在循环处理的时候，检查下文件是否存在：

# POSIX

for i in *.mp3; do

[ -e "$i" ] || continue

some command "$i"

done

如果你有使用引号和避免单词拆分的习惯，你完全可以避免很多错误。

注意下循环体内部的"$i"，这里会导致下面我们要说的另外一个比较容易犯的错误。

2. cp $file $target

上面的命令有什么问题呢？如果你提前知道，$file和$target文件名中不会包含空格或者*号。否则，这行命令执行前在经过单词拆分和文件名展开的时候会出现问题。所以，两次强调，在使用展开的地方切勿忘记使用引号：

$ cp -- "$file" "$target"

如果不带引号，当你执行如下命令时就会出错：

$ file="01 - Don't Eat the Yellow Snow.mp3"

$ target="/tmp"

$ cp $file $target

cp: cannot stat ‘01’: No such file or directory

如果带上引号，就不会有上面的问题，除非文件名以'-'开头，在这种情况下，cp会认为你提供的是一个命令行选项，这个错误下面会介绍。

3. 文件名中包含短横'-'

文件名以'-'开头会导致许多问题，*.mp3这种通配符会根据当前的locale展开成一个列表，但在绝大多数环境下，'-'排序的时候会排在大多数字母前。这个展开的列表传递给有些命令的时候，会错误的将-filename解析成命令行选项。这里有两种方法来解决这个问题。

第一种方法是在命令和参数之间加上--，这种语法告诉命令不要继续对--之后的内容进行命令行参数/选项解析：

$ cp -- "$file" "$target"

这种方法可以解这个问题，但是你需要在每个命令后面都要加上--，而且依赖具体的命令解析的方式，如果一些命令不兼容这种约定俗成的规范，这种做法是无效的。

另外一种方法是，确保文件名都使用相对或者绝对的路径，以目录开头：

for i in ./*.mp3; do

cp "$i" /target

...

done

这种情况下，即使某个文件以-开头，展开后文件名依然是./-foo.mp3这种形式，完全不会有问题。

4. [ $foo = "bar" ]

这是一个与第2个问题类似的问题，虽然用到了引号，但是放错了位置，对于字符串字面值，除非有特殊符号，否则不大需要用引号括起来。但是，你应该把变量的值用括号括起来，从而避免它们包含空格或能通配符，这一点我们在前面的问题中都解释过。

这个例子在以下情况下会出错：

如果[中的变量不存在，或者为空，这个时候上面的例子最终解析结果是：

[ = "bar" ] # 错误!

并且执行会出错：unary operator expected，因为=是二元操作符，它需要左右各一个操作数。

如果变量值包含空格，它首先在执行之前进行单词拆分，因此[命令看到的样子可能是这样的：

[ multiple words here = "bar" ];

正确的做法应该是：

# POSIX

[ "$foo" = bar ]

这种写法，在POSIX兼容的实现中都不会有问题，即使$foo以短横"-"开头，因为POSIX实现的test命令通过传递的参数来确定执行的行为。

只有一些非常古老的shell可能会遇到问题，这个时候你可以使用下面的写法来解决（相信你肯定看到过这种写法）：

# POSIX / Bourne

[ x"$foo" = xbar ]

在Bash中，还有另外一种选择是使用[[关键字：

# Bash / Ksh

[[ $foo == bar ]]

这里你不需要使用引号，因为在[[里面参数不会进行展开，当然带上引号也不会有错。

不过有一点要注意的是，[[里的==不仅仅是文本比较，它会检查左边的值是否匹配右侧的表达式，==右侧的值加上引号，会让它成为一个普通的字面量，*?等通配符会失去特殊含义。

5. cd $(dirname "$f")

这又是一个引号的问题，命令展开的结果会进一步地进行单词拆分或者文件名展开。因此下面的写法才是正确的：

cd "$(dirname "$f")"

但是，上面引号的写法可能比较怪异，你可能会认为第一、二个引号，第三、四个引号是一组的。

但是事实上，Bash将命令替换里面的引号当成一组，外面的当成另外一组。如果你是用反引号的写法，引号的行为就不是这样的了，所以$()写法更加推荐。

6. [ "$foo" = bar && "$bar" = foo ]

不要在test命令内部使用&&，Bash解析器会把你的命令分隔成两个命令，在&&之前和之后。你应该使用下面的写法：

[ bar = "$foo" ] && [ foo = "$bar" ] # POSIX

[[ $foo = bar && $bar = foo ]] # Bash / Ksh

尽量避免使用下面的写法，虽然它是正确的，但是这种写法可移植性不好，并且已经在POSIX-2008中被废弃：

[ bar = "$foo" -a foo = "$bar" ]

7. [[ $foo > 7 ]]

原文作者认为算术比较不应该用[[，而是用((，我没弄明白是为什么。

如果有理解的同学，欢迎以评论回复，谢谢。

8. grep foo bar | while read -r; do ((count++)); done

这种写法初看没有问题，但是你会发现当执行完后，count变量并没有变化。原因是管道后面的命令是在一个子Shell中执行的。

POSIX规范并没有说明管道的最后一个命令是不是在子Shell中执行的。一些shell，例如ksh93或者Bash>=4.2可以通过shopt -s lastpipe命令，指明管道中的最后一个命令在当前shell中执行。由于篇幅限制，在此就不展开，有兴趣的可以看Bash FAQ #24。

9. if [grep foo myfile]

初学者会错误地认为，[是if语法的一部分，正如C语言中的if ()。但是事实并非如此，if后面跟着的是一个命令，[是一个命令，它是内置命令test的简写形式，只不过它要求最后一个参数必须是]。下面两种写法是一样的：

# POSIX

if [ false ]; then echo "HELP"; fi

if test false; then echo "HELP"; fi

两个都是检查参数"false"是不是非空的，所以上面两个语句都会输出HELP。

if语句的语法是：

if COMMANDS

then <COMMANDS>

elif <COMMANDS> # optional

then <COMMANDS>

else <COMMANDS> # optional

fi # required

再次强调，[是一个命令，它同其它常规的命令一样接受参数。if是一个复合命令，它包含其它命令，[并不是if语法中的一部分。

如果你想根据grep命令的结果来做事情，你不需要把grep放到[里面，只需要在if后面紧跟grep即可：

if grep -q fooregex myfile; then

...

如果grep在myfile中找到匹配的行，它的执行结果为0(true)，then后面的部分就会执行。

10. if [bar="$foo"]; then ...

正如上一个问题中提到的，[是一个命令，它的参数之间必须用空格分隔。

11. if [ [ a = b ] && [ c = d ] ]; then ...

不要用把[命令看成C语言中if语句的条件一样，它是一个命令。

如果你想表达一个复合的条件表达式，可以这样写：

if [ a = b ] && [ c = d ]; then ...

注意，if后面有两个命令，它们用&&分开。等价于下面的写法：

if test a = b && test c = d; then ...

如果第一个test(或者[)命令返回false，then后面的语句不会执行；如果第一个返回true，第二个test命令会执行；只有第二个命令同样返回true的情况下，then后面的语句才会执行。

除此之外，还可以使用[[关键字，因为它支持&&的用法：

if [[ a = b && c = d ]]; then ...

12. read $foo

read命令中你不需要在变量名之前使用$。如果你想把读入的数据存放到名为foo的变量中，下面的写法就够了：

read foo

或者，更加安全地方法：

IFS= read -r foo

read $foo会把一行的内容读入到变量中，该变量的名称存储在$foo中。所以两者的含义是完全不一样的。

13. cat file | sed s/foo/bar/ > file

你不应该在一个管道中，从一个文件读的同时，再往相同的文件里面写，这样的后果是未知的。

你可以为此创建一个临时文件，这种做法比较安全可靠：

# sed 's/foo/bar/g' file > tmpfile && mv tmpfile file

或者，如果你用得是 GNU Sed 4.x 以上的版本，可以使用-i 选项即时修改文件的内容：

# sed -i 's/foo/bar/g' file

14. echo $foo

这种看似无害的命令往往会给初学者千万极大的困扰，他们会怀疑是不是因为 $foo 变量的值是错误的。事实却是因为，$foo 变量在这里没有使用双引号，所以在解析的时候会进行单词拆分和文件名展开，最终导致执行结果与预期大相径庭：

msg="Please enter a file name of the form *.zip"

echo $msg

这里整句话会被拆分成单词，然后其中的通配符会被展开，例如*.zip。当你的用户看到如下的结果时，他们会怎样想：

Please enter a file name of the form freenfss.zip lw35nfss.zip

再举一个例子（假设当前目录下有以 .zip 结尾的文件）：

var="*.zip" # var 包括一个星号，一个点号和 zip

echo "$var" # 输出 *.zip

echo $var # 输出所有以 .zip 结尾的文件

实际上，这里使用 echo 命令并不是绝对的安全。例如，当变量的值包含-n时，echo 会认为它是一个合法的选项而不是要输出的内容（当然如果你能够保证不会有-n 这种值，可以放心地使用 echo 命令）。

完全可靠的打印变量值的方法是使用 printf：

printf "%s\n" "$foo"

15. $foo=bar

略过

16. foo = bar

当赋值时，等号两边是不允许出现空格的，这同 C 语言不一样。当你写下 foo = bar 时，shell 会将该命令解析成三个单词，然后第一个单词 foo 会被认为是一个命令，后面的内容会被当作命令参数。

同样地，下面的写法也是错误的：

foo= bar # WRONG!

foo =bar # WRONG!

$foo = bar; # COMPLETELY WRONG!

正确的写法应该是这样的：

foo=bar # Right.

foo="bar" # More Right.

17. echo <<EOF

当脚本需要嵌入大段的文本内容时，here document往往是一个非常有用的工具，它将其中的文本作为命令的标准输入。不过，echo 命令并不支持从标准输入读取内容，所以下面的写法是错误的：

# This is wrong:

echo <<EOF

Hello world

How's it going?

EOF

正确的方法是，使用 cat 命令来完成：

# This is what you were trying to do:

cat <<EOF

Hello world

How's it going?

EOF

或者可以使用双引号，它也可以跨越多行，而且因为 echo 命令是内置命令，相同情况下它会更加高效：

echo "Hello world

How's it going?"

18. su -c 'some command'

这种写法“几乎”是正确的。问题是，在许多平台上，su 支持 -c 参数，但是它不一定是你认为的。比如，在 OpenBSD 平台上你这样执行会出错：

$ su -c 'echo hello'

su: only the superuser may specify a login class

在这里，-c是用于指定login-class。如果你想要传递 -c 'some command' 给 shell，最好在之前显示地指定 username：

$ su root -c 'some command' # Now it's right.

19. cd /foo; bar

如果你不检查 cd 命令执行是否成功，你可以会在错误的目录下执行 bar 命令，这有可能会带来灾难，比如 bar 命令是 rm -rf *。

你必须经常检查 cd 命令执行是否有错误，简单的做法是：

cd /foo && bar

如果在 cd 命令后有多个命令，你可以选择这样写：

cd /foo || exit 1

bar

baz

bat ... # Lots of commands.

出错时，cd 命令会报告无法改变当前目录，同时将错误消息输出到标准错误，例如"bash: cd: /foo: No such file or directory"。如果你想要在标准输出同时输出自定义的错误提示，可以使用复合命令（command grouping）:

cd /net || { echo "Can't read /net. Make sure you've logged in to the Samba network, and try again."; exit 1; }

do_stuff

more_stuff

注意，在{号和 echo 之间需要有一个空格，同时}之前要加上分号。

顺便提一下，如果你要在脚本里频繁改变当前目录，可以看看 pushd/popd/dirs 等命令，可能你在代码里面写的 cd/pwd 命令都是没有必要的。

说到这，比较下下面两种写法：

find ... -type d -print0 | while IFS= read -r -d '' subdir; do

here=$PWD

cd "$subdir" && whatever && ...

cd "$here"

done

find ... -type d -print0 | while IFS= read -r -d '' subdir; do

(cd "$subdir" || exit; whatever; ...)

done

下面的写法，在循环中 fork 了一个子 shell 进程，子 shell 进程中的 cd 命令仅会影响当前 shell的环境变量，所以父进程中的环境命令不会被改变；当执行到下一次循环时，无论之前的 cd 命令有没有执行成功，我们会回到相同的当前目录。这种写法相较前面的用法，代码更加干净。

20. [ bar == "$foo" ]

正确的用法:

[ bar = "$foo" ] && echo yes

[[ bar == $foo ]] && echo yes

21. for i in {1..10}; do ./something &; done

你不应该在&后面添加分号，删除它：

for i in {1..10}; do ./something & done

或者改成多行的形式：

for i in {1..10}; do ./something & done

&和分号一样也可以用作命令终止符，所以你不要将两个混用到一起。一般情况下，分号可以被换行符替换，但是不是所有的换行符都可以用分号替换。

22. cmd1 && cmd2 || cmd3

有些人喜欢把&&和||作为if...then...else...fi 的简写语法，在多数情况下，这种写法没有问题。例如：

[[ -s $errorlog ]] && echo "Uh oh, there were some errors." || echo "Successful."

但是，这种结构并不是在所有情况下都完全等价于 if...fi 语法。这是因为在&&后面的命令执行结束时也会生成一个返回码，如果该返回码不是真值（0代表 true），||后面的命令也会执行，例如：

i=0

true && ((i++)) || ((i--))

echo $i # 输出 0

看起来上面的结果应该是返回1，但是结果却是输出0，为什么呢？原因是这里 i++ 和 i-- 都执行了一遍。

其中，((i++))命令执行算术运算，表达式计算的结果为0。这里和 C 语言一样，表达式的结果为0被认为是 false。所以当 i=0 的时候，((i++))命令执行的返回码为1（false），从而会执行接下来的((i--))命令。

如果我们在这里使用前缀自增运算符的话，返回的结果恰恰为1，因为((++i))执行的返回码是0（true）：

i=0

true && (( ++i )) || (( --i ))

echo $i # Prints 1

不过在你无法保证 y 的执行结果是，绝对不要依靠 x && y || z这种写法。上面这种巧合，在 i 初始化为-1时也会有问题。

如果你喜欢代码更加安全健壮，建议使用 if...fi 语法：

i=0

if true; then

((i++))

else

((i--))

echo $i # 输出 1

23. echo "Hello World!"

在交互式的 Shell 环境下，你执行以上命令会遇到下面的错误：

bash: !": event not found

这是因为，在默认的交互式 Shell 环境下，Bash 发现感叹号时会执行历史命令展开。在 Shell 脚本中，这种行为是被禁止的，所以不会发生错误。

不幸地是，你认为明显正确地修复方法，也不能工作，你会发现反斜杠并没有转义感叹号：

# echo "hi\!"

hi\!

最简单地方法是禁用 histexpand 选项，你可以通过 set +H 或者 set +o histexpand 命令来完成。

下面四种写法都可以解决：

# 1. 使用单引号

echo 'Hello World!'

# 2. 禁用 histexpand 选项

set +H

echo "Hello World!"

# 3. 重置 histchars

histchars=

# 4. 控制 shell 展开的顺序，命令行历史展开是在单词拆分之前执行的

# 参见：Bash man 手册的History Expansion一节 exmark='!'

echo "Hello, world$exmark"

24. for arg in $*

和大多数 Shell 一样，Bash 支持依次读取单个命令行参数的语法。不过这并是$*或者$@，这两种写法都不正确，它们只能得到完整的参数列表，并非单独的一个个参数。

正确的语法是（没错要加上引号）：

for arg in "$@"

# 或者更简单的写法

for arg

在脚本中遍历所有参数是一个再普遍不过的需求，所以 for arg 默认等价于 for arg in "$@"。$@使用双引号后就有特殊的魔力，每个参数展开后成为一个独立的单词。（"$@"等价于"$1" "$2" "$3" ...）

下面是一个错误的例子:

for x in $*; do echo "parameter: '$x'" done

执行的结果为：

$ ./myscript 'arg 1' arg2 arg3

parameter: 'arg'

parameter: '1'

parameter: 'arg2'

parameter: 'arg3'

正确的写法：

for x in "$@"; do echo "parameter: '$x'" done

执行的结果为：

$ ./myscript 'arg 1' arg2 arg3

parameter: 'arg 1'

parameter: 'arg2'

parameter: 'arg3'

上面正确的例子中，第一个参数'arg 1'在展开后依然是一个独立的单词，而不会被拆分成两个。

25. function foo()

这种写法不一定能够兼容所有 shell，兼容的写法是：

foo() { ... }

26. echo "~"

波浪号展开（Tilde expansion）仅当~没有引号的时候发生，在上面的例子中，只会向标准输出打印~符号，而不是当前用户的家目录路径。

当用引号将路径参数引起来时，

如果要用引号将相对于家目录的路径引起来时，推荐使用 $HOME 而不是 ~, 假如 $HOME 目录是"/home/my photos"，路径中包含空格。

下面是几组例子：

"~/dir with spaces" # expands to "~/dir with spaces"

~"/dir with spaces" # expands to "~/dir with spaces"

~/"dir with spaces" # expands to "/home/my photos/dir with spaces"

"$HOME/dir with spaces" # expands to "/home/my photos/dir with spaces"

27. local varname=$(command)

当在函数中声明局部变量时，local作为一个独立的命令，这种奇特的行为有时候可能会导致困扰。比如，当你想要捕获命令替换的返回码时，你就不能这样做。local命令的返回码会覆盖它。

这种情况下，你只能分成两行写：

local varname

varname=$(command) rc=$?

28. export foo=~/bar

export 与 local 命令一样，并不是赋值语句的一部分。因此，在有些 Shell 下（比如Bash），export foo=~/bar会展开，但是有些（比如 Dash）却不行。

下面是两种比较健壮的写法：

foo=~/bar; export foo # Right!

export foo="$HOME/bar" # Right!

29. sed 's/$foo/good bye/'

单引号内部不会展开 $foo变量，在这里可以换成双引号：

foo="hello"; sed "s/$foo/good bye/"

但是要注意，如果你使用了双引号，就需要考虑更多转义的事情，具体可以看Quotes这一页。.

30. tr [A-Z] [a-z]

这里至少有三个问题。第一个问题是， [A-Z] 和 [a-z] 会被 shell 认为是通配符。如果在当前目录下没用文件名为单个字母的文件，这个命令似乎能正确执行，否则会错误地执行，也许你会在周末耗费许多小时来修复这个问题。

第二个问题是，这不是 tr 命令正确的写法，实际上，上面的命令会把[转换成[，将任意大写字符转换成对应的小写字符，将]转换成]，所以你根本不需要加上括号，这样第一个问题就可以解决了。

第三个问题是，上面的命令执行结果依赖于当前的 locale，A-Z 或者 a-z 不一定会代表26个 ASCII 字母。实际上，在一些语言环境下，z 位于字母表的中间位置。这个问题的解法，取决于你希望发生的行为是哪一种。

如果你仅希望改变26个英文字母的大小写（强制 locale为 C）：

LC_COLLATE=C tr A-Z a-z

如果你希望根据实际的语言环境来转换：

tr '[:upper:]' '[:lower:]'

31. ps ax | grep gedit

这里的根本问题是正在运行的进程名称，本质上是不可靠的。可能会有多个合法的gedit进程，也有可能是别的东西伪装成gedit进程（改变执行命令名称是一件简单的事情）,更多细节可以看ProcessManagement这一篇文章。

执行以上命令，往往会在结果中包含 grep 进程：

# ps ax | grep gedit

10530 ? S 6:23 gedit

32118 pts/0 R+ 0:00 grep gedit

这个时候，需要过滤多余的结果：

# ps ax | grep -v grep | grep gedit

上面的写法比较丑陋，另外一种方法是：

# ps ax | grep [g]edit

32. printf "$foo"

如果$foo 变量的值中包括\或者%符号，上面命令的执行结果可能会出乎你的意料之外。

下面是正确的写法：

printf %s "$foo"

printf '%s\n' "$foo"

33. for i in {1..$n}

Bash的命令解释器会优先展开大括号，所以这时大括号{}表达式里面看到的是文字上的$n（没有展开）。$n 不是一个数值，所以这里的大括号{}并不会展开成数字列表。可见，这导致很难使用大括号来展开大小只能在运行时才知道的列表。

可以用下面的方法：

for ((i=1; i<=n; i++)); do ... done

注：之前我也有写过一篇文章来介绍这个问题：Shell生成数字序列。

34. if [[ $foo = $bar ]]

在[[内部，当=号右边的值没有用引号引起来，bash 会将它当作模式来匹配，而不是一个简单的字符串。所以，在上面的例子中，如果 bar 的值是一个*号，执行的结果永远是 true。

所以，如果你想检查两侧的字符串是否相同，等号右侧的值一定要用引号引起来。

if [[ $foo = "$bar" ]]

如果你确实要执行模式匹配，聪明的做法是取一个更加有意义的变量名（例如$patt），或者加上注释说明。

35. if [[ $foo =~ 'some RE' ]]

同上，如果=~号右侧的值加上引号，它会散失特殊的正则表达式含义，而变成一个普通的字符串。

如果你想使用一个长的或者复杂的正则表达式，避免大量的反斜杠转义，建议把它放在一个变量中：

re='some RE' if [[ $foo =~ $re ]]

36. [ -n $foo ] or [ -z $foo ]

这个例子中，$foo 没有用引号引起来，当$foo包含空格或者$foo为空时都会出问题：

$ foo="some word" && [ -n $foo ] && echo yes -bash: [: some: binary operator expected

$ foo="" && [ -n $foo ] && echo yes

yes

正确的写法是：

[ -n "$foo" ]

[ -z "$foo" ]

[ -n "$(some command with a "$file" in it)" ]

[[ -n $foo ]]

[[ -z $foo ]]

37. [[ -e "$broken_symlink" ]] returns 1 even though $broken_symlink exists

这里-e 选项是看文件是否存在，当紧跟的文件是一个软链接时，它不看软链接是否存在，而是看实际指向的文件是否存在。所以当软链接损坏时，即实际指向的文件被删除后，-e 的结果返回1。

所以如果你确实要判断后面的文件是否存在，正确的写法是：

[[ -e "$broken_symlink" || -L "$broken_symlink" ]]

38. ed file <<<"g/d\{0,3\}/s//e/g" fails

ed 命令使用的正则语法，不支持0次出现次数，下面的就可以正常工作：

ed file <<<"g/d\{1,3\}/s//e/g"

略过，现在很少会有人用 ed 命令吧。

39. expr sub-string fails for "match"

下面的例子多数情况下运行不会有问题：

word=abcde

expr "$word" : ".$.*$" bcde

但是当 $work 不巧刚好是 match 时，就有可能出错了（MAC OSX 下的 expr 命令不支持 match，所以依然能正常工作）：

word=match

expr "$word" : ".$.*$"

原因是 match 是 expr 命令里面的一个特殊关键字，针对 GNU系统，解决方法是在前面加一个'+'：

word=match

expr + "$word" : ".$.*$" atch

'+'号可以让 expr 命令忽略后续 token 的特殊含义。

另外一个建议是，不要再使用 expr 命令了，expr 能做的事情都可以用 Bash 原生支持的参数展开（Parameter Expansion）或者字符串展开（Substring Expansion）来完成。并且相同情况下，内置的功能肯定比外部命令的效率要高。

上面的例子，目的是为了删除单词中的首字符，可以这样做：

$ word=match

$ echo "${word#?}" # PE

atch

$ echo "${word:1}" # SE

atch

40. On UTF-8 and Byte-Order Marks (BOM)

多数情况下，UNIX 下 UTF-8 类型的文本不需要使用 BOM，文本的编码是根据当前语言环境，MIME类型或者其它文件元数据信息确定的。人为阅读时，不会因为在文件开始处加 BOM 标记而腚影响，但是当文件要被脚本解释执行时，BOM 标记会像 MS-DOS 下的换行符（^M）一样奇怪。

41. content=$(<file)

这里没有什么错误，不过你要知道命令替换会删除结尾多余的换行符。

略过，原文给的优化方法需要 Bash 4.2+ 以上的版本，手头没有这样的环境。

42. somecmd 2>&1 >>logfile

这是一个很常见的错误，显然你本来是想将标准输出与标准错误输出都重定向到文件logfile 中，但是你会惊讶地发现，标准错误依然输出到屏幕中。

这种行为的原因是，重定向在命令执行之前解析，并且是从左往右解析。上面的命令可以翻译成，将标准错误输出重定向到标准输出（此刻是终端），然后将标准输出重定向到文件 logfile 中。所以，到最后，标准错误并没有重定向到文件中，而是依然输出到终端：

somecmd >>logfile 2>&1

更加详细的说明见BashFAQ。

43. cmd; (( ! $? )) || die

只有需要捕获上一个命令的执行结果进，才需要记录$?的值，否则如果你只需要检查上一个命令是否执行成功，直接检测命令：

if cmd; then ... fi

或者使用 case 语句来检测多个或能的返回码：

cmd

status=$?

case $status in

echo success >&2

;;

echo 'Must supply a parameter, exiting.' >&2

exit 1

;;

echo 'Unknown error, exiting.' >&2

exit $status

esac

推荐文章：

Bash编程易犯的错误