linux脚本 trap,linux shell trap的使用

linux shell编程 trap命令

trap命令用于指定在接收到信号后将要采取 的行 动，我们将在本书后面的内容中详细介绍信号。trap命令的一种常见用途是在脚本程序被中断时完成清理工作。历史上，shell总是用数字来代表信号，而 新的脚本程序应该使用信号的名字，它们保存在用#include命令包含进来的signal.h头文件中，在使用信号名时需要省略SIG前缀。你可以在命 令提示符下输入命令trap -l来查看信号编号及其关联的名称。

对于那些不熟悉信号的人们来说，“信号”是指那些被异步发送到一个程序的事件。默认情况下，它们通常会终止一个程序的运行。

trap命令的参数分为两部分，前一部分是接收到指定信号时将要采取的行动，后一部分是要处理的信号名。

请记住，脚本程序通常是以从上到下的顺序解释执行的，所以必须在你想保护的那部分代码以前指定trap命令。

如果要重置某个信号的处理条件到其默认值，只需简单的将command设置为-。如果要忽略某个信号，就把command设置为空字符串‘’。一个不带参数的trap命令将列出当前设置的信号及其行动的清单。

表2-11列出了X/Open规范里面规定的能够被捕获的比较重要的一些信号(括号里面的数字是传统的信号编号)。更多细节请参考signal在线手册的第七部分(man 7 signal)。

表 2-11

信     号说     明

HUP(1)挂起，通常因终端掉线或用户退出而引发

INT(2)中断，通常因按下Ctrl+C组合键而引发

QUIT(3)退出，通常因按下Ctrl+组合键而引发

ABRT(6)中止，通常因某些严重的执行错误而引发

ALRM(14)报警，通常用来处理超时

TERM(15)终止，通常在系统关机时发送

实验：信号处理

下面的脚本演示了一些简单的信号处理方法：

运行这个脚本，在每次循环时按下Ctrl+C组合键(或任何你系统上设定的中断键)，我们将得到如下所示的输出：

实验解析

在这个脚本程序中，我们先用trap命令安排它在出 现一个INT(中断)信号时执行rm –f /tmp/my_tmp_file_$$命令删除临时文件。脚本程序然后进入一个while循环，只要临时文件存在，循环就一直持续下去。当用户按下 Ctrl+C组合键时，就会执行rm –f /tmp/my_tmp_file_$$语句，然后继续下一个循环。因为临时文件现在已经被删除了，所以第一个while循环将正常退出。

接下来，脚本程序再次调用trap命令，这次是指定 当一个INT信号出现时不执行任何命令。脚本程序然后重新创建临时文件并进入第二个while循环。这次当用户按下Ctrl+C组合键时，没有语句被指定 执行，所以采取默认处理方式，即立即终止脚本程序。因为脚本程序被立即终止了，所以永远也不会执行最后的echo和exit语句。

16．unset命令

unset命令的作用是从环境中删除变量或函数。这个命令不能删除shell本身定义的只读变量(如IFS)。这个命令并不常用。

下面的脚本第一次输出字符串“Hello World”，但第二次只输出一个换行符：

使用foo=语句产生的效果与上面脚本中的unset命令产生的效果差不多，但并不等同。foo=语句将变量foo设置为空，但变量foo仍然存在。而使用unset foo语句的效果是把变量foo从环境中删除

ctrl+c，涉及到前台进程组，和终端设置属性有关。其意义就是说，当按下ctrl+c时候，(前提是stty -a看到，intr=^C，很多系统默认是del)，终端驱动程序检测到，并且根据这个stty的设定，给每个属于前台进程组(进程组可以有很多，但是任一时刻，只能有一个前台进程组)，给该组的每个进程都发送SIGINT。首先，要明确，一般的shell实现而言，如果是用交互式shell来运行，为了方便问题叙述，假定我们现在的shell是bash那么ksh -i -c "cmd"和ksh -c "cmd"在ksh -i 模式下，cmd和ksh不是一个进程组，ksh和bash又不是一个进程组。在ksh直接-c没有-i模式下，一般的实现而言，ksh和cmd是一个进程组，而ksh和bash不是一个进程组。为什么是这个结果？ 想想看？这样我们可以分析，有个x.sh文件trap "cmd" sigxxxxxx我们会sh  x.sh 或者直接x.sh不过不论什么模式，都会有当前的登录shell启动一个子shell来执行这个x.sh。而且，该shell和x.sh中需要启动的子进程都是一个进程组(观察到这点很重要)。因为如果不是交互模式的shell来执行，则该子shell和其子进程都会属于一个进程组(除非被调用的cmd又重新设置了其组id)，否则，子shell和其子shell属于不同的进程组。为什么ctrl+c会中断该子shell和其子进程呢(不论是否交互shell启动)，原因就在于，当非交互式启动，他们自然是一个组，都属于同一个前台进程组。当交互式启动时候，他们不属于同一个进程组，但是请注意，一个进程只要有控制终端(ps -f时候，能看到tty不是？的就是)，就能让自己参加该前台进程组(注意，参加前台进程组，不会改变自己的组id)。事实上，我们也可以看到，在交互模式启动下，子shell和其子进程不是一个组，但是他们也属于同一个前台进程组。并且该前台进程组号就是子shell的子进程的组号。因此我们可以推想，子shell，为了一直保持和其子进程在同一个前台进程组，不断的调用了tcsetpgrp，来参加其子进程所在的组。否则，按照现在unix的规则，就会发现，ctrl+c后，子shell不会终止，但是其子进程会终止！这当然不是我们想要的。以上的阐述，综合起来就是三句话：1，ctrl+c(如果就是终端产生SIGINT设置的话)，会送到当前的前台进程组的每一个进程。2，前台进程组里的进程，可以都是同一个组，也可以不是同一个组。3，前台进程组是一个终端属性，同一终端，任一时刻，最多只能有一个前台进程组。事实上，shell trap一个信号，并非是wait子进程的退出态，如果不是正常结束(128+信号数值)，就调用trap。恰恰相反，是shell为自己设定了一个信号处理，因为他和子进程是同一个前台进程组，因此，可以得到从终端驱动发送到该组每个成员的一个信号(并非shell无法直接获得SIGINT)，在自己收到SIGINT时候，即触发自己设定的动作。这一点，其实可以通过一个简单的实验证实：x.sh在trap 后，执行调用一个很小的C程序编译后的binary，该C文件实现为一直等待，捕捉SIGINT后exit(0)。这样x.sh就会认为该子进程是正常结束？按照cjaizss 的说法，就会得出，x.sh本身不会触发trap的动作。实际上，肯定会的。其实有个更简单的测试。

sh -c "trap 'echo ok' 2; sh -c \"trap 'exit 0' 2; read\""