Linux Shell 编程实战技巧
来源:互联网 发布:kill me heal me 知乎 编辑:程序博客网 时间:2024/06/10 03:05
我从其他人的Shell脚本中学到的
【感谢@Elliptic_Yang 的热心翻译。如果其他朋友也有不错的原创或译文,可以尝试推荐给伯乐在线。】
我是一个Shell脚本迷,也很喜欢从其他人的Shell脚本里学习一些有趣的东西。最近我偶然接触到用于方便ssh服务器双重认证的 authy-ssh 脚本。 浏览脚本后我学到了一些很酷的东西,在此也想分享给大家。
1. 让你的echo丰富多彩
很多时候,你会想让echo能以多种颜色区分不同输出。比如,绿色表示成功,红色告知失败,黄色提示警告。
NORMAL=$(tput sgr0)
GREEN=$(tput setaf 2; tput bold)
YELLOW=$(tput setaf 3)
RED=$(tput setaf 1)
function
red() {
echo
-e
"$RED$*$NORMAL"
}
function
green() {
echo
-e
"$GREEN$*$NORMAL"
}
function
yellow() {
echo
-e
"$YELLOW$*$NORMAL"
}
# To print success
green
"Task has been completed"
# To print error
red
"The configuration file does not exist"
# To print warning
yellow
"You have to use higher version."
这里使用 tput
来配置输出颜色,输出文本,最后再恢复默认输出颜色。如果想对 tpu
了解更多,参看 prompt-color-using-tput 。
2. 输出debug信息
仅当设置DEBUG标志时才打印调试信息。
function
debug() {
if
[[ $DEBUG ]]
then
echo
">>> $*"
fi
}
# For any debug message
debug
"Trying to find config file"
还有来自于一些很酷的Geeks的单行debug函数:
function
debug() { ((DEBUG)) &&
echo
">>> $*"
; }
function
debug() { [
"$DEBUG"
] &&
echo
">>> $*"
; }
3. 检查特定的可执行文件是否存在
OK=0
FAIL=1
function
require_curl() {
which
curl &>
/dev/null
if
[ $? -
eq
0 ]
then
return
$OK
fi
return
$FAIL
}
这里使用 which
命令来查找可执行文件 curl
的路径。如果成功找到,则可执行文件文件是存在的,否则就不存在。 &>/dev/null
将标准输出和标准错误重定向到 /dv/null
(也就是不显示在终端上了)。
一些朋友建议可以直接使用 which
返回的状态码。
# From cool geeks at hacker news
function
require_curl() {
which
"curl"
&>
/dev/null
; }
function
require_curl() {
which
-s
"curl"
; }
4. 显示脚本的使用说明
在我开始写Shell脚本的初期,常会使用 echo
命令显示脚本的使用说明。 但当说明的文字较多时,echo
语句就会变得一团糟。随后我发现,可以使用 cat
命令来显示使用说明。
cat
<< EOF
Usage: myscript <
command
> <arguments>
VERSION: 1.0
Available Commands
install
- Install package
uninstall - Uninstall package
update - Update package
list - List packages
EOF
这里的 <<
称为 here document,它可以将字符串放置在两个 EOF 之间。
5. 用户设置 vs. 默认配置
我们有时会希望在用户没有提供设置参数时能够使用默认值。
URL=${URL:-http:
//localhost
:8080}
这一语句检查环境变量 URL ,如果不存在,就将其设置为 localhost
。
6. 检查字符串的长度
if
[ ${
#authy_api_key} != 32 ]
then
red
"you have entered a wrong API key"
return
$FAIL
fi
${#VARIABLE_NAME}
可以给出字符串的长度。
7. 为读取输入设置时限
READ_TIMEOUT=60
read
-t
"$READ_TIMEOUT"
input
# if you do not want quotes, then escape it
input=$(
sed
"s/[;\`\"\$\' ]//g"
<<< $input)
# For reading number, then you can escape other characters
input=$(
sed
's/[^0-9]*//g'
<<< $input)
8. 获取目录名和文件名
# To find base directory
APP_ROOT=`
dirname
"$0"
`
# To find the file name
filename=`
basename
"$filepath"
`
# To find the file name without extension
filename=`
basename
"$filepath"
.html`
完结。 祝各位编程开心,享受这美好的一天吧!
Linux Shell 编程实战技巧
目前,越来越多的企业应用会部署在 Linux 系统上的,而 Linux Shell 脚本可以极大地帮助我们完成这些应用的运维任务。这使得 Linux Shell 开发技能成为开发人员的一项重要的、有竞争力的技能。本文就笔者的实际开发经验,以 Korn Shell 为例分享了脚本开发中的常见问题及相关技巧。
避免定时任务脚本的常见问题
很多脚本在实际使用的时候往往是以定时任务的方式运行,而非手工运行。但是实现同样功能的脚本在这两种运行方式下可能遇到的问题不尽相同。
以定时任务方式运行的脚本往往会遇到以下几个问题。
- 路径问题:当前目录往往不是脚本文件所在目录。因此,脚本在引用其使用的外部文件,如配置文件和其它脚本文件时,无法方便得使用相对路径。
- 命令找不到问题:脚本中使用到的一些外部命令,在手工执行脚本的时候可以正常调用。但是在定时任务下运行则可能出现脚本解析器找不到相关命令的问题。
- 脚本重复运行问题:一次脚本的执行未结束,而下一次脚本的运行已经开始。导致系统中有多个进程在同时运行同一个脚本。
下面分享定时任务脚本开发中上述几个常见问题的处理方法。
路径问题
定时任务下当前路径往往不是脚本文件所在目录。因此我们需要用绝对路径来引用。即先获取脚本所在目录,然后以该目录为基础采用绝对路径的方式去引用脚本所需的外部文件。方法如下面代码所示。
清单 1. 获取脚本文件所在路径
#!/usr/bin/ksh
echo
"Current path is: `pwd`"
scriptPath=`
dirname
$0`
#获取脚本所在路径
echo
"The script is located at: $scriptPath"
cat
"$scriptPath/readme"
#使用绝对路径引用外部文件
将清单 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. 解决找不到外部命令问题
source
/home/oracle/
.profile
也就说,对于外部命令找不到的问题,可以通过在脚本的开头加一个 source 用户的.profile 文件的语句来解决。
脚本重复运行问题
定时任务脚本的另外一个常见问题是脚本重复运行的问题。比如,一个脚本被设置为每 5 分钟运行一次。若某一次该脚本的运行无法在 5 分钟内结束的话,定时任务服务仍然会新启一个进程来执行该脚本。这时就出现了运行同一个脚本的多个进程。而这可能导致脚本功能紊乱。并且浪费了系统资源。 避免脚本重复运行的方法通常有两种。一是在脚本执行时先检查系统是否存在运行该脚本的其它进程。若存在,则终止当前脚本的运行。二是,脚本运行时检查系统中是否存在其它进程运行该脚本。若存在,则结束那个进程(此方法有一定风险,慎用!)。这两种方法均需要在脚本的开头检查系统是否已经存在运行当前脚本的进程,若存在这样的进程则获取该进程的 PID。示例代码如下清单 3 所示。
清单 3. 防止脚本重复运行方法 1
#!/usr/bin/ksh
main(){
selfPID=
"$$"
scriptFile=
"$0"
typeset existingPid
existingPid=`getExistingPIDs $selfPID
"$scriptFile"
`
if
[ ! -z
"$existingPid"
];
then
echo
"The script already running, exiting..."
exit
-1
fi
doItsTask
}
#获取除本身进程以外其它运行当前脚本的进程的 PID
getExistingPIDs(){
selfPID=
"$1"
scriptFile=
"$2"
ps
-ef |
grep
"/usr/bin/ksh ${scriptFile}"
|
grep
-
v
"grep"
|
awk
"{ if(\$2!=$selfPID) print \$2 }"
}
doItsTask(){
echo
"Task is now being executed..."
sleep
20
#睡眠 20s,以模拟脚本在执行需要长时间完成的任务
}
main $*
清单 4. 防止脚本重复运行方法 2
#!/usr/bin/ksh
main(){
selfPID=
"$$"
scriptFile=
"$0"
typeset existingPid
existingPid=`getExistingPIDs $selfPID
"$scriptFile"
`
if
[ ! -z
"$existingPid"
];
then
echo
"The script already running, killing it..."
kill
-9
"$existingPid"
#此方法有一定风险,慎用!
fi
doItsTask
}
#获取除本身进程以外其它运行当前脚本的进程的 PID
getExistingPIDs(){
selfPID=
"$1"
scriptFile=
"$2"
ps
-ef |
grep
"/usr/bin/ksh ${scriptFile}"
|
grep
-
v
"grep"
|
awk
"{ if(\$2!=$selfPID) print \$2 }"
}
doItsTask(){
echo
"Task is now being executed..."
sleep
20
#睡眠 20s,以模拟脚本在执行需要长时间完成的任务
}
main $*
脚本调试技巧
虽然 Shell 开发的一个普遍问题是调试困难,缺乏有效的调试工具。但是,我们可以采取一些能够一定程度上帮助我们规避调试困难的开发与调试的方式。 由于是脚本开发,不少人习惯于从直接地一行行地写代码,一个脚本里面甚至于一个函数都没有。虽然这种方式在语法上和功能上并无问题。但这增加了调试的难度。相反,如果采用模块化的方式去编写脚本,则使代码结构清晰、便于调试。这点,可以看这样一个例子。
假设下面的脚本的功能是收集生产环境中的相关日志文件,用于定位问题。需要收集的日志文件包括操作系统日志、中间件日志以及应用系统本身的日志。这些文件会被压缩成一个 gz 文件。
清单 5. 自动收集日志文件
#!/usr/bin/ksh
main(){
collectSyslog
#收集系统日志文件
collectMiddlewareLog
#收集中间件日志文件
collectAppLog
#收集应用系统日志文件
tar
-zcf logs.tgz syslog.zip mdwlog.zip applog.zip
#将三中类型的日志打包,方便下载
}
若脚本执行报如下错误:
tar: applog.zip: Cannot stat: No such file or directory
我们可以很快锁定 collectAppLog 这个函数。因为它负责输出 applog.zip 这个文件。而没有必要看代码中的其它部分。
采用模块化的方式的另一个好处是代码调试的结果可以巩固下来。比如上面的例子中,如果你已经调试好了操作状态日志收集的函数。接下来调试其它函数的时候,这些被调试的代码尽管可能需要改动。但是这些改动影响到之前已经调试好的代码的可能并不大。相反,若是一个脚本中通篇都是语句,而不带函数,则改动其中一行代码,收集三种日志的功能可能都受影响。
另外一个典型的场景是脚本编写过程中,我们可能会因为不太确定一些问题如何处理而写一些尝试性的代码。然后,通过反复的调试去确认正确的处理方式。而事实上这些尝试性的代码可能就是一条语句甚至一个命令。但不少人是在大段的代码中反复去调试这一小段代码。这将非常耗时间。尤其是调试过程中代码中的其它部分调试时出现错误时,作者还得先解决其它错误,否则可能会时我们真正要调试的代码无法被执行到。这种情形下,专门写一个测试性的小脚本。
在该脚本中调试还我们不太确定该如何写的代码,如何将其”集成”到我们正在开发的脚本中。这样可以提高调试效率,避免消耗本不该消耗的时间。比方说,我们在编写过程中需要获取脚本本身所在进程的进程 ID。而此时我们又不太确定这个获取当前进程 id 的代码该怎么写。那么,我们可以新建一个测试性的脚本在其中尝试实现这个获取进程 ID 的功能。找到正确的方法后,将代码“移植”到我们真正要开发的脚本中。
处理大段字符输出
脚本开发中经常要处理的一个问题是输出提示信息。当然,对于简短的提示信息输出,使用 echo 命令就足够了。但是,对于大段的提示信息输出仍然使用 echo 命令处理则显得不够优雅。一种更适合的方法是使用 cat 命令结合输入重定向。下面通过一个具体例子来说明这点。
假设下面的脚本会将某个程序安装到用户指定的目录下。若用户指定的目录不存在,则提示
用户检查指定的目录是否正确,并重新执行脚本。
清单 6. 使用 echo 命令输出大段字符
#!/usr/bin/ksh
path=
"$1"
if
[ ! -d
"$path"
];
then
#这里还必需处理星号这个特殊字符的显示
echo
'****************************************************'
echo
ERROR
echo
"The destination directory not exists,make sure below directory you specified is correct:"
echo
${path}
echo
"Then re-run this script."
echo
'****************************************************'
fi
这种方式的代码可读性不是很好,阅读者需要阅读多个 echo 命令然后再进行”综合”才能准确理解提示信息是什么。另外,一旦提示信息需要改动。这种改动可能因为改动其中一个 echo 命令时不小心多了一个双引号等特殊字符而引起语法错误,从而影响了整个脚本的执行。
清单 7 的代码则展示了如何使用 cat 命令和输入重定向来更好地处理大段文本的输出。
清单 7. 使用 cat 命令输出大段字符
#!/usr/bin/ksh
path=
"$1"
if
[ ! -d
"$path"
];
then
cat
<<EOF
****************************************************
ERROR
The destination directory not exists,
make
sure below
directory you specified is correct:
${path}
Then re-run this script.
****************************************************
EOF
fi
显然,这种处理方式的代码更加简洁,可读性更好。阅读者只需要看一条命令,就知道提示信息的具体内容。并且,若要修改提示语,我们可以放心地在两个文件终止符 EOF 之间的部分改。即便修改错了,也不会影响到代码中的其它部分。
避免使用非必要的临时文件
新手在编写 Shell 脚本时往往在不必要使用临时文件的情况下使用了临时文件。这不仅增加了而外的代码编写工作量(用于处理创建、读取、和删除临时文件等),而且可能使脚本运行速度变慢(文件 I/O 毕竟不是快的操作)。
下面的例子中假设有个脚本的功能是往当前目录下所有的.txt 文件中添加如下一行文本:
–End of file name–
清单 8.和清单 9.中的代码分别显示了在不必要使用临时文件的情况下使用临时文件的代码和不需要使用临时文件的代码。
清单 8. 在不必要使用临时文件的情况下使用临时文件
#!/usr/bin/ksh
ls
-lt *.txt |
awk
'{print $NF}'
> tmp
#将命令输出重定向到临时文件 tmp
cat
tmp
typeset fileName
typeset lastLine
while
read
fileName
#逐行读取临时文件中的每一行
do
lastLine=`
tail
-1
"$fileName"
`
if
[ !
"$lastLine"
==
"--End of $fileName--"
];
then
echo
"--End of $fileName--"
>> $fileName
fi
done
<tmp
#从临时文件进行输入重定向
rm
tmp
#删除临时文件
清单 9. 不使用临时文件
#!/usr/bin/ksh
typeset fileName
typeset lastLine
for
fileName
in
$(
ls
-lt *.txt |
awk
'{print $NF}'
)
do
lastLine=`
tail
-1
"$fileName"
`
if
[ !
"$lastLine"
==
"--End of $fileName--"
];
then
echo
"--End of $fileName--"
>> $fileName
fi
done
使用支持 FTP 功能的编辑器
如果你的开发环境是在 Windows 操作系统下,而测试则是通过终端软件(如 Putty)在 Linux上进行。这种情形下,不少开发者习惯于在终端软件上直接编辑脚本(如使用 vi 命令)。显然,这种方式编辑效率低下。并且,脚本开发往往需要边修改边测试。即使是一个语法错误,由于缺乏工具的支持,我们可能要通过运行脚本才能发现。因此,提高脚本编辑效率某种程度上便提高了开发效率。在 Windows 系统上开发脚本时提高脚本编辑效率的一个不错的选择是使用支持简单的 FTP 功能的编辑器,如 Editplus 和 UltraEditor。可以使用这些编辑器以 FTP 的方式“打开”(实际上就是下载)Linux 测试主机上的脚本文件。编辑好脚本后对脚本进行保存时,这些编辑器会自动将脚本上传到测试主机上。接下来只需通过终端软件对脚本进行测试。如果测试后脚本需要继续修改,则可以利用编辑器的“重新载入文档”的功能(通常可以为该功能设置快捷键)。
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- Linux Shell 编程实战技巧
- linux shell编程小技巧
- Linux shell脚本编程技巧
- 实战Linux Shell 编程与服务器管理
- 实战Linux shell编程与服务器管理
- 实战Linux Shell编程与服务器管理
- RSA java 加密长文本
- Ubuntu的『杂记』
- 眼球取代键盘,指日可待
- ios7内购、Game Center 实现 in-App Purchases & Game Center
- X-Cart 学习笔记(一)了解和安装X-Cart
- Linux Shell 编程实战技巧
- mybaits批量操作数据库
- ucos中的三种临界区管理机制(OS_CRITICAL_METHOD的解释)
- ObjectiveC基础-ivar是什么意思
- Windows(x64)编译FFMPEG-2.0.1
- 第四章 网络层 4.2网际协议IP
- 学习笔记6
- jsp页面的js的书写规范
- RHEL 6.3安装(超级详细图解教程)