先介绍一点背景 - 当我apt-get install从公司互联网下载时，它会在前 10 秒左右提供高速爆发（400-500KB/s），然后下降到该速度的十分之一（40-50KB/s），然后几分钟后到了一个真正的惨（4-5KB/s）。这让我觉得系统管理员已经实施了某种网络节流方案。

现在我知道网络不仅仅是不稳定的，因为如果我启动一个apt-get install foo，Ctrl-C它会在 10 秒后立即apt-get install foo再次运行（通过向上箭头并输入使用 bash 历史记录），然后继续重复这个过程几分钟直到所有包都下载了，我可以非常快地下载大包。特别是，即使在使用 Ctrl-C 中止下载后，apt-get 似乎也能够在下一次调用中恢复下载。

当然，盯着屏幕每 10 秒执行一次 Ctrl-C Up Enter 真的很无聊，所以我写了一个 shell 脚本 -

这似乎有效。它生成 apt-get，运行 10 秒，然后杀死（通过发送 SIGINT）并再次启动它。但是，它并没有真正起作用，因为现在 apt-get 不会在后续调用中恢复下载！

我sudo apt-get install foo从一个终端运行然后kill -2 <PID of apt-get>从另一个终端运行的实验。即使在这种情况下，当我重新启动 apt-get 时，它也不会恢复下载。

很明显，Ctrl-C不等同于 SIGINT。当我手动执行 Ctrl-C 时，还会发生其他事情，这让 apt-get 有机会保存下载状态。问题是——它是什么？

编辑

这些是我到目前为止收到的建议，但没有雪茄。谜底加深！-

1. 在sudo kill -2 $!信号上可能会去sudo而不是apt-get。这不是原因，因为如上所述，我还尝试将 SIGINT 专门发送到 apt-get 的 PID，甚至阻止 apt-get 保存其状态。

2. Sudo 捕获信号并将其他一些信号发送到 apt-get。我尝试发送 apt-get 所有我能想到的信号！它仍然不会恢复其中任何一个的下载。只有当我按 Ctrl-C 杀死它时，它才会恢复下载。

3. 如果 SIGINT 来自脚本而不是交互式 shell，则 Apt-get 处理 SIGINT 的方式不同。再一次，上面的“实验”证明这不是真的。

My console app traps SIGINT so it can exit gracefully.

Pressing CTRL+C inside XCode while the program is being debugged, though, has no effect.

I can find the process and use a terminal window to send a SIGINT to my process, however I'm hoping there's a simpler solution that I can do within XCode.

在 MATLAB GUI 应用程序中，我启动了一个外部程序（Windows 上的控制台应用程序），负责从测量系统读取数据。数据存储在几个文件中，一旦外部程序完成，MATLAB 应用程序就会处理这些文件。问题是这样的：

外部程序在命令行上运行时，可以通过发出 SIGINT（即按Ctrl+ C）优雅地停止。信号处理程序捕获 SIGINT 并关闭程序。有没有办法在 MATLAB GUI 应用程序中通过按下“中止”按钮来执行此操作？

经过数小时的搜索，我偶然发现了http://www.caam.rice.edu/~wy1/links/mex_ctrl_c_trick/，它显示了如何在 MEX 文件中检测 SIGINT。让 MEX 调用外部程序可能会起作用（尽管我还不确定细节）。但是，它仍然需要Ctrl+C来停止程序。如何通过 GUI 中的按钮发送 SIGINT？

我有一个完美运行的 C++（Android 原生）应用程序。然后我引入了一些try { } catch {}语句，如果我调试应用程序，它会以随机、正确的代码片段疯狂地中断。如果我运行应用程序，它会因中断而停止 Zygote ( app_process ) 抱怨信号2，即SIGINT。

在我添加大量 try-catch 子句之前，我的应用程序中有一些运行良好的 try-catch 子句。在这一点上，我确定有很多嵌套的 try-catch 块，也许 Android 操作系统无法处理嵌套块的那么多中断？

我想提一下，在 Windows 上，相同的代码可以完美运行。

通常我可以用 Ctrl+C 打断东西，但有时当我使用线程时它不起作用——下面的例子。

编辑： 有没有办法回到口译员那里？到目前为止的解决方案完全杀死 python 和你现有的命名空间..

我对 Python 很陌生，所以如果这个问题非常基本，请原谅我。

我正在尝试在使用选择模块从套接字接受数据时处理键盘中断。所以，我有一个 select.select() 函数调用来等待来自套接字的数据，然后将其输出到控制台。

按下 CTRL_C 时，似乎有时会出现 select.error，有时会出现 exceptions.IOError 异常。两种异常对应的错误代码均为 4。

有一些代码在调用堆栈中更深地处理 KeyboardInterrupt 异常，因此当我在接受套接字连接的函数中获得 SIGINT 时，我只想重新引发 KeyboardInterrupt 异常。我还想捕获与连接相关的异常。

检查异常的错误代码是否安全，如果它是 4 则引发 KeyboardInterrupt？这会影响我捕获与连接相关的异常的能力吗？有没有关于错误代码的好资源？

谢谢！

我正在阅读How do we capture CTRL ^ C - Perl Monks，但我似乎无法获得正确的信息来帮助解决我的问题。

问题是 - 我有一个无限循环，并且“多行”打印输出到终端（我知道我会被告知要ncurses改用 -​​ 但对于短脚本，我更愿意写一堆printfs）。我想以这样的方式捕获 Ctrl-C，即脚本仅在此多行打印输出完成后才会终止。

脚本是（Ubuntu Linux 11.04）：

现在，如果我运行它，然后按 Ctrl-C，我会得到类似这样的东西（注意，_脚本终止后终端光标的指示位置）：

或者：

...但是，我想得到：

显然，处理程序正在运行——但并不完全按照我期望的时间（或顺序）运行。有人可以澄清我该如何解决这个问题，所以我得到我想要的输出？

非常感谢您的任何答案，干杯！

当我看到如何在 bash 中使用 Perl 陷阱 Ctrl-C (sigint) 时；我迷失了为什么它会因线程而失败；我正在尝试以下脚本：

...一旦 SIGINT 处理程序设置为默认值以外的任何其他值（其中 Ctrl-C 导致 exit），它基本上会导致脚本不再对 Ctrl-C 做出反应：

...我必须sudo killall perl为了终止脚本。

这些链接中有一些关于线程和 Ctrl-C 的内容：

• 将 sig INT ( 控制 C ) 发送到线程 - Dev Shed
• 已解决：这是 perl 线程的错误吗？- Perl 僧侣
• 我们如何捕获 CTRL ^ C - Perl Monks
• 信号处理程序应该像这样工作吗？

...但我不能说它是否最终回答了在 bash 中的 perl 下“捕获”Ctrl-C 是否绝对不可能？

提前感谢您的任何答案，
干杯！

好的，我想我明白了（但我将上一个条目（下）留作参考......）

诀窍是，从主 SIGINT 处理程序，必须通过kill- 向线程发出信号，然后线程还需要有一个单独的 SIGINT 处理程序（来自 OP 中的第一个链接）；并且不仅仅是join()，需要使用@ikegami 的答案中的代码：

我可能用$toexit那里过度杀戮它，但至少现在这是结果：

非常感谢大家的解决方案:)
干杯！

感谢@mob 的建议PERL_SIGNALS（unsafe注意，Perl 5.14 不允许 $ENV{'PERL_SIGNALS'} 的“内部”设置），我到了某个地方 - 现在检测到 Ctrl-C - 但它要么以段错误，或有错误：

有了上面的注释，该代码的反应是：

如果我添加使用Perl::Signals::Unsafe的以下内容，结果是相同的：

快到了，希望有人能插话……:)

所以这是我的代码：

现在我对 signal() 的理解是，当收到 SIGINT 命令（Ctrl+C对吗？）时，我的函数 sigHandle 应该用整数值 2（SIGINT 编号）调用，该方法应该运行并且程序不应该退出。

我想做的只是打印信号编号并继续前进，但是在打印出“信号：2”后它会退出。

（最终我应该处理前 32 个中断，但我认为Ctrl+C将是最困难的，所以我从这里开始。）

如果我主要做信号（SIGINT，SIG_IGN）；它正确地忽略了信号并且没有退出，但我现在无法知道我是否收到了 SIGINT 中断。

早些时候我在玩 sigaction 结构，但我找不到任何真正全面的文档，所以我决定只使用“原始”信号处理。

这是我的 sigaction 代码（与上述相同的问题）：

谢谢你的帮助！

编辑

好的，所以在通过手册页和互联网浏览了很多很多小时后，我遇到了一个（非常）贫民窟解决方案，其中涉及保存堆栈预无限循环，然后当中断来临时，做我需要做的事情，然后重新设置堆栈回到原来的位置并调用 sigrelse() 命令重新设置任何可能已更改但未重新加载的状态。

我知道这不是解决这个问题的最优雅/最有效/甚至不是社会可接受的解决方案，但它有效，据我所知，我没有在任何地方泄漏任何内存，所以一切都很好......

我仍在寻找解决此问题的方法，并且我认为我的堆栈重新设置恶作剧只是一个临时修复...

谢谢！

我一直在调试一个 Python 程序，该程序在收到KeyboardInterrupt异常后会出现段错误。这通常是通过Ctrl+C从外壳按下来完成的。为了测试特定的代码更改是否修复了这个错误，我有一个小的 shell 脚本，它SIGINT在启动后随机发送给程序。我遇到的问题是发送Ctrl+C似乎对程序的影响与发送信号不同SIGINT，因此不会导致错误出现，所以我很想知道这两个动作之间有什么区别。

该程序根本不会捕获任何键盘操作，只是一个带有一些线程/进程的 python 程序。它不安装信号处理程序（尽管 Python 会），并stty -a提供intr = ^C. 我怀疑它可能是Ctrl+C发送SIGINT到所有子进程/线程，而kill -INT只发送到主进程，但这就是我的怀疑。

这是发送kill -INT.