我从其他人的Shell脚本中学到的
Khan。欢迎加入技术翻译小组。转载请参见文章末尾处的要求。
【感谢@Elliptic_Yang 的热心翻译。如果其他朋友也有不错的原创或译文，可以尝试推荐给伯乐在线。】
我是一个Shell脚本迷，也很喜欢从其他人的Shell脚本里学习一些有趣的东西。最近我偶然接触到用于方便ssh服务器双重认证的 authy-ssh 脚本。 浏览脚本后我学到了一些很酷的东西，在此也想分享给大家。
1. 让你的echo丰富多彩
很多时候，你会想让echo能以多种颜色区分不同输出。比如，绿色表示成功，红色告知失败，黄色提示警告。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
NORMAL=$(tputGREEN=$(tputYELLOW=$(tputRED=$(tputfunction echo"$RED$*$NORMAL"}function echo"$GREEN$*$NORMAL"}function echo"$YELLOW$*$NORMAL"}#green"Task#red"The#yellow"You |
这里使用 tput 来配置输出颜色，输出文本，最后再恢复默认输出颜色。如果想对 tpu 了解更多，参看 prompt-color-using-tput 。
2. 输出debug信息
仅当设置DEBUG标志时才打印调试信息。
|
1
2
3
4
5
6
7
8
9
|
function if then echo fi}#debug"Trying |
还有来自于一些很酷的Geeks的单行debug函数：
|
1
2
|
functionecho;function"$DEBUG"echo; |
3. 检查特定的可执行文件是否存在
|
1
2
3
4
5
6
7
8
9
10
11
12
|
OK=0FAIL=1function which/dev/null ifeq then return fi return} |
这里使用 which 命令来查找可执行文件 curl 的路径。如果成功找到，则可执行文件文件是存在的，否则就不存在。 &>/dev/null 将标准输出和标准错误重定向到 /dv/null （也就是不显示在终端上了）。
一些朋友建议可以直接使用 which 返回的状态码。
|
1
2
3
|
#functionwhich/dev/null;functionwhich"curl"; |
4. 显示脚本的使用说明
在我开始写Shell脚本的初期，常会使用 echo 命令显示脚本的使用说明。 但当说明的文字较多时，echo 语句就会变得一团糟。随后我发现，可以使用 cat命令来显示使用说明。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
catUsage:command>VERSION:Available install uninstall update listEOF |
这里的 << 称为 here
document，它可以将字符串放置在两个 EOF 之间。
5. 用户设置 vs. 默认配置
我们有时会希望在用户没有提供设置参数时能够使用默认值。
|
1
|
URL=${URL:-http://localhost:8080} |
这一语句检查环境变量 URL ，如果不存在，就将其设置为 localhost。
6. 检查字符串的长度
|
1
2
3
4
5
|
if#authy_api_key}then red"you returnfi |
${#VARIABLE_NAME} 可以给出字符串的长度。
7. 为读取输入设置时限
|
1
2
3
4
5
6
7
8
|
READ_TIMEOUT=60read"$READ_TIMEOUT"#input=$(sed#input=$(sed |
8. 获取目录名和文件名
|
1
2
3
4
5
6
7
8
|
#APP_ROOT=`dirname`#filename=`basename`#filename=`basename |
完结。 祝各位编程开心，享受这美好的一天吧!
Linux Shell 编程实战技巧
目前，越来越多的企业应用会部署在 Linux 系统上的，而 Linux Shell 脚本可以极大地帮助我们完成这些应用的运维任务。这使得 Linux Shell 开发技能成为开发人员的一项重要的、有竞争力的技能。本文就笔者的实际开发经验，以 Korn Shell 为例分享了脚本开发中的常见问题及相关技巧。
避免定时任务脚本的常见问题
很多脚本在实际使用的时候往往是以定时任务的方式运行，而非手工运行。但是实现同样功能的脚本在这两种运行方式下可能遇到的问题不尽相同。
以定时任务方式运行的脚本往往会遇到以下几个问题。
- 路径问题：当前目录往往不是脚本文件所在目录。因此，脚本在引用其使用的外部文件，如配置文件和其它脚本文件时，无法方便得使用相对路径。
- 命令找不到问题：脚本中使用到的一些外部命令，在手工执行脚本的时候可以正常调用。但是在定时任务下运行则可能出现脚本解析器找不到相关命令的问题。
- 脚本重复运行问题：一次脚本的执行未结束，而下一次脚本的运行已经开始。导致系统中有多个进程在同时运行同一个脚本。
下面分享定时任务脚本开发中上述几个常见问题的处理方法。
路径问题
定时任务下当前路径往往不是脚本文件所在目录。因此我们需要用绝对路径来引用。即先获取脚本所在目录，然后以该目录为基础采用绝对路径的方式去引用脚本所需的外部文件。方法如下面代码所示。
清单 1. 获取脚本文件所在路径
|
1
2
3
4
5
6
7
|
#!/usr/bin/kshechoscriptPath=`dirname#获取脚本所在路径echocat |
将清单 1 中的脚本置于目录/opt/demo/scripts/auto-task 下，并在 cron 中添加该脚本。定时任务运行输出如下。
Current path is: /home/viscent
The script is located at: /opt/demo/scripts/auto-task
命令找不到问题
定时任务下运行的脚本可能出现脚本解析器找不到相关命令的问题。比如 Oracle 数据库中的 sqlplus 命令，脚本在调用该命令时若没有特殊处理则在定时任务下执行会使脚本解析器无法找到这个命令，出现如下所示的错误提示：
sqlplus: command not found
这是因为脚本在定时任务下执行时脚本是由非登录式 Shell 来执行的，并且执行脚本的父 Shell 并非 Oracle 用户的 Shell。因此，此时 Oracle 用户的.profile 文件并没有被调用。故解决的方法是在脚本的开头添加以下代码：
清单 2. 解决找不到外部命令问题
|
1
|
source.profile |
也就说，对于外部命令找不到的问题，可以通过在脚本的开头加一个 source 用户的.profile 文件的语句来解决。
脚本重复运行问题
定时任务脚本的另外一个常见问题是脚本重复运行的问题。比如，一个脚本被设置为每 5 分钟运行一次。若某一次该脚本的运行无法在 5 分钟内结束的话，定时任务服务仍然会新启一个进程来执行该脚本。这时就出现了运行同一个脚本的多个进程。而这可能导致脚本功能紊乱。并且浪费了系统资源。 避免脚本重复运行的方法通常有两种。一是在脚本执行时先检查系统是否存在运行该脚本的其它进程。若存在，则终止当前脚本的运行。二是，脚本运行时检查系统中是否存在其它进程运行该脚本。若存在，则结束那个进程（此方法有一定风险，慎用！）。这两种方法均需要在脚本的开头检查系统是否已经存在运行当前脚本的进程，若存在这样的进程则获取该进程的
PID。示例代码如下清单 3 所示。
清单 3. 防止脚本重复运行方法 1
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
#!/usr/bin/kshmain(){selfPID="$$"scriptFile="$0"typesetexistingPid=`getExistingPIDs"$scriptFile"`if"$existingPid"then echo exitfidoItsTask}#获取除本身进程以外其它运行当前脚本的进程的getExistingPIDs(){selfPID="$1"scriptFile="$2"psgrepgrepvawk}doItsTask(){echosleep#睡眠}main |
清单 4. 防止脚本重复运行方法 2
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
#!/usr/bin/kshmain(){selfPID="$$"scriptFile="$0"typesetexistingPid=`getExistingPIDs"$scriptFile"`if"$existingPid"then echo kill"$existingPid"fidoItsTask}#获取除本身进程以外其它运行当前脚本的进程的getExistingPIDs(){selfPID="$1"scriptFile="$2"psgrepgrepvawk}doItsTask(){echosleep#睡眠}main |
脚本调试技巧
虽然 Shell 开发的一个普遍问题是调试困难，缺乏有效的调试工具。但是，我们可以采取一些能够一定程度上帮助我们规避调试困难的开发与调试的方式。 由于是脚本开发，不少人习惯于从直接地一行行地写代码，一个脚本里面甚至于一个函数都没有。虽然这种方式在语法上和功能上并无问题。但这增加了调试的难度。相反，如果采用模块化的方式去编写脚本，则使代码结构清晰、便于调试。这点，可以看这样一个例子。
假设下面的脚本的功能是收集生产环境中的相关日志文件，用于定位问题。需要收集的日志文件包括操作系统日志、中间件日志以及应用系统本身的日志。这些文件会被压缩成一个 gz 文件。
清单 5. 自动收集日志文件
|
1
2
3
4
5
6
7
8
|
#!/usr/bin/kshmain(){collectSyslog#收集系统日志文件collectMiddlewareLog#收集中间件日志文件collectAppLog#收集应用系统日志文件tar#将三中类型的日志打包，方便下载} |
若脚本执行报如下错误:
tar: applog.zip: Cannot stat: No such file or directory
我们可以很快锁定 collectAppLog 这个函数。因为它负责输出 applog.zip 这个文件。而没有必要看代码中的其它部分。
采用模块化的方式的另一个好处是代码调试的结果可以巩固下来。比如上面的例子中，如果你已经调试好了操作状态日志收集的函数。接下来调试其它函数的时候，这些被调试的代码尽管可能需要改动。但是这些改动影响到之前已经调试好的代码的可能并不大。相反，若是一个脚本中通篇都是语句，而不带函数，则改动其中一行代码，收集三种日志的功能可能都受影响。
另外一个典型的场景是脚本编写过程中，我们可能会因为不太确定一些问题如何处理而写一些尝试性的代码。然后，通过反复的调试去确认正确的处理方式。而事实上这些尝试性的代码可能就是一条语句甚至一个命令。但不少人是在大段的代码中反复去调试这一小段代码。这将非常耗时间。尤其是调试过程中代码中的其它部分调试时出现错误时，作者还得先解决其它错误，否则可能会时我们真正要调试的代码无法被执行到。这种情形下，专门写一个测试性的小脚本。
在该脚本中调试还我们不太确定该如何写的代码，如何将其”集成”到我们正在开发的脚本中。这样可以提高调试效率，避免消耗本不该消耗的时间。比方说，我们在编写过程中需要获取脚本本身所在进程的进程 ID。而此时我们又不太确定这个获取当前进程 id 的代码该怎么写。那么，我们可以新建一个测试性的脚本在其中尝试实现这个获取进程 ID 的功能。找到正确的方法后，将代码“移植”到我们真正要开发的脚本中。
处理大段字符输出
脚本开发中经常要处理的一个问题是输出提示信息。当然，对于简短的提示信息输出，使用 echo 命令就足够了。但是，对于大段的提示信息输出仍然使用 echo 命令处理则显得不够优雅。一种更适合的方法是使用 cat 命令结合输入重定向。下面通过一个具体例子来说明这点。
假设下面的脚本会将某个程序安装到用户指定的目录下。若用户指定的目录不存在，则提示
用户检查指定的目录是否正确，并重新执行脚本。
清单 6. 使用 echo 命令输出大段字符
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
#!/usr/bin/kshpath="$1"if"$path"then #这里还必需处理星号这个特殊字符的显示echoechoechoechoechoechofi |
这种方式的代码可读性不是很好，阅读者需要阅读多个 echo 命令然后再进行”综合”才能准确理解提示信息是什么。另外，一旦提示信息需要改动。这种改动可能因为改动其中一个 echo 命令时不小心多了一个双引号等特殊字符而引起语法错误，从而影响了整个脚本的执行。
清单 7 的代码则展示了如何使用 cat 命令和输入重定向来更好地处理大段文本的输出。
清单 7. 使用 cat 命令输出大段字符
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
#!/usr/bin/kshpath="$1"if"$path"thencat<<EOF****************************************************ERRORThemakedirectory${path}Then****************************************************EOFfi |
显然，这种处理方式的代码更加简洁，可读性更好。阅读者只需要看一条命令，就知道提示信息的具体内容。并且，若要修改提示语，我们可以放心地在两个文件终止符 EOF 之间的部分改。即便修改错了，也不会影响到代码中的其它部分。
避免使用非必要的临时文件
新手在编写 Shell 脚本时往往在不必要使用临时文件的情况下使用了临时文件。这不仅增加了而外的代码编写工作量（用于处理创建、读取、和删除临时文件等），而且可能使脚本运行速度变慢（文件 I/O 毕竟不是快的操作）。
下面的例子中假设有个脚本的功能是往当前目录下所有的.txt 文件中添加如下一行文本：
–End of file name–
清单 8.和清单 9.中的代码分别显示了在不必要使用临时文件的情况下使用临时文件的代码和不需要使用临时文件的代码。
清单 8. 在不必要使用临时文件的情况下使用临时文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
#!/usr/bin/kshlsawk#将命令输出重定向到临时文件cattypesettypesetwhile#逐行读取临时文件中的每一行do lastLine=`tail"$fileName"` if"$lastLine""--End then echo fidone#从临时文件进行输入重定向rm#删除临时文件 |
清单 9. 不使用临时文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
#!/usr/bin/kshtypesettypesetforinlsawk)do lastLine=`tail"$fileName"` if"$lastLine""--End then echo fidone |
使用支持 FTP 功能的编辑器
如果你的开发环境是在 Windows 操作系统下，而测试则是通过终端软件(如 Putty)在 Linux上进行。这种情形下，不少开发者习惯于在终端软件上直接编辑脚本(如使用 vi 命令)。显然，这种方式编辑效率低下。并且，脚本开发往往需要边修改边测试。即使是一个语法错误，由于缺乏工具的支持，我们可能要通过运行脚本才能发现。因此，提高脚本编辑效率某种程度上便提高了开发效率。在 Windows 系统上开发脚本时提高脚本编辑效率的一个不错的选择是使用支持简单的 FTP 功能的编辑器，如 Editplus 和 UltraEditor。可以使用这些编辑器以
FTP 的方式“打开”(实际上就是下载)Linux 测试主机上的脚本文件。编辑好脚本后对脚本进行保存时，这些编辑器会自动将脚本上传到测试主机上。接下来只需通过终端软件对脚本进行测试。如果测试后脚本需要继续修改，则可以利用编辑器的“重新载入文档”的功能(通常可以为该功能设置快捷键)。