Bash:当脚本终止时,如何终止脚本的子进程?
该问题适用于如下脚本:
脚本
#!/bin/sh
SRC="/tmp/my-server-logs"
echo "STARTING GREP JOBS..."
for f in `find ${SRC} -name '*log*2011*' | sort --reverse`
do
(
OUT=`nice grep -ci -E "${1}" "${f}"`
if [ "${OUT}" != "0" ]
then
printf '%7s : %s\n' "${OUT}" "${f}"
else
printf '%7s %s\n' "(none)" "${f}"
fi
) &
done
echo "WAITING..."
wait
echo "FINISHED!"
当前行为
在控制台中按 Ctrl+C
会终止脚本,但不会终止已在运行的 grep
进程。
The question applies to a script such as the following:
Script
#!/bin/sh
SRC="/tmp/my-server-logs"
echo "STARTING GREP JOBS..."
for f in `find ${SRC} -name '*log*2011*' | sort --reverse`
do
(
OUT=`nice grep -ci -E "${1}" "${f}"`
if [ "${OUT}" != "0" ]
then
printf '%7s : %s\n' "${OUT}" "${f}"
else
printf '%7s %s\n' "(none)" "${f}"
fi
) &
done
echo "WAITING..."
wait
echo "FINISHED!"
Current behavior
Pressing Ctrl+C
in console terminates the script but not the already running grep
processes.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
为
Ctrl+c
编写一个陷阱,并在陷阱中杀死所有子进程。将其放在wait
命令之前。Write a trap for
Ctrl+c
and in the trap kill all of the subprocesses. Put this before yourwait
command.一个简单的替代方案是使用
cat
管道。以下内容对我有用:如果我在最后一个数字打印到标准输出之前按 Ctrl-C。如果文本生成命令需要很长时间(例如“find /”),它也可以工作,即不仅通过 cat 到 stdout 的连接被杀死,而且实际上是子进程。
对于广泛使用子进程的大型脚本,确保缩进的 Ctrl-C 行为的最简单方法是将整个脚本包装到这样的子 shell 中,例如,
我不确定这是否与安德鲁的答案具有完全相同的效果(即我'我不确定发送到子进程的信号是什么)。另外,我只使用 cygwin 进行了测试,而不是使用本机 Linux shell 进行了测试。
A simple alternative is using a
cat
pipe. The following worked for me:If I press Ctrl-C before the last number is printed to stdout. It also works if the text-generating command is something that takes a long time such as "find /", i.e. it is not only the connection to stdout through cat that is killed but actually the child process.
For large scripts that make extensive use of subprocesses the easiest way to ensure the indented Ctrl-C behaviour is wrapping the whole script into such a subshell, e.g.
I am not sure though if this has the exactly same effect as Andrew's answer (i.e. I'm not sure what signal is sent to the subprocesses). Also I only tested this with cygwin, not with a native Linux shell.