上次升级 Fedora 后,X 终端应用程序开始出现奇怪的行为。我似乎无法使用Ctrl+停止任何进程C,它只会导致打印^C
到控制台。同样,Ctrl+Z会打印^Z
,进程继续。两者在非图形虚拟控制台中都可以正常工作。
我检查了一下stty -a
,一切看起来都很正常:
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
这与终端无关(gnome-terminal、XFCE4 终端、xterm)。后来我注意到,这可能根本不是由终端引起的:直接发送到相应进程的 INT 或 TSTP 也被忽略。这包括我过去经常使用Ctrl+终止的各种应用程序C(并且通常没有更好的退出方式):、、、、、、当cat
卡find
在损坏的文件上时...tail -f
java
ping
mplayer
当我想中断一个我输入的命令行然后又改变主意时,它甚至bash
会忽略Ctrl+ (在这种情况下会打印 no)。我需要逐个字符地删除它(如果使用了文件名补全,则可能会有数百个字符)或故意运行不需要的命令。奇怪的是,它确实识别+ — 当然,只是说它是“使用 :quit”。C^C
vim
CtrlC
这非常烦人,让我无法高效工作。直到最近,大概一周前,一切都正常。我在 Google 上找不到任何可能的原因,也许我尝试了错误的搜索词或错误地识别了主要问题。这可能是什么原因,我该如何恢复标准行为?
更新
Ctrl+Z作品有时。似乎在我登录后启动的第一个终端中它会停止正在运行的命令,但之后就停止工作了。
答案1
我怀疑你的桌面环境。你使用哪一个?
新的答案。
从 init 到 shell 的路径上的某些东西将 SIGINT 和 SIGTSTP 设置为忽略。这最终会被 shell 继承。您可以使用这个小程序生成任何将信号重置为默认值的程序。
#include <signal.h>
int main(int argc, char **argv)
{
signal(SIGTSTP, SIG_DFL);
signal(SIGINT, SIG_DFL);
execvp(argv[1], argv+1);
}
答案2
这里有一个与已经提供的解决方法类似的解决方法。它不需要您编写特殊程序,因此有些人可能会觉得它更方便。
exec ksh -c 'exec $SHELL'
如果您还没有安装,ksh
请安装。yum install ksh
答案3
对于任何可能面临同样问题的人来说:
我采用了 fstx 解决方案的变体,目前它在所有情况下(嵌套登录、SSH 等)都运行良好。
需要用 C 编写一个小实用程序,进行编译并将其放在以下位置$PATH
:
sig.c
#include <signal.h>
#include <unistd.h>
int main(int argc, char **argv)
{
sigset_t mask;
sigfillset(&mask);
sigprocmask(SIG_UNBLOCK, &mask, NULL);
return execvp(argv[1], argv+1);
}
然后,在最开始的这个小检查.bashrc
确保没有信号被阻塞:
if ( grep SigBlk /proc/self/status | grep -qv 00000 )
then
exec sig $0 $@
fi