Red Hat Bugzilla – Bug 79414
Control-C fails to interrupt foreground process
Last modified: 2007-04-18 12:48:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830
Description of problem:
Hitting Control-C (Ctrl-C, ^C, C-c) is supposed to interrupt the foreground
process running in the terminal. This works on the Linux console, in xterm, and
even in the old gnome-terminal, but it doesn't work anymore in Red Hat Linux 8.0.
I've tried turning the options for menu mnemonics and access key on and off in
Edit->Keybindings, but they don't make any difference.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch gnome-terminal
2. In terminal, start a long-running interruptible process, such as
ls -R /
3. Make sure the terminal is focused, and hit Control-C
Actual Results: The process doesn't stop. You have to kill it from another
command line or close the window, which is annoying.
Expected Results: Hitting Control-C should interrupt the process.
Try the same thing in xterm; it works there.
This problem has been alluded to in the comments of bug 75740: another user
complained that Control-C doesn't kill "tail -f".
Oddly, Control-C does interrupt the ping command, though.
I've tested a number of programs that require a significant amount of time to
execute and I've been able to kill it each time with CTRL+C. I would suggest
that you update your version of the vte package (the widget used to provide
terminal emulation for GTK+ 2 applications). I think I am running an old
rawhide version of vte (0.8.19-1), and it has been working fine for me. I just
checked rawhide and noticed that it has been updated to 0.10.5-2. vte has been
in a constant state of flux since the release of Red Hat and the later versions
cure many problems with the shipping version of the package.
$ rpm -q gnome-terminal
$ rpm -q vte
I've heard no other reports of this, and have not seen it myself.
I would expect a large number of reports if people were seeing this.
If you can track down in more detail how to reproduce then please do.
Note that ctrl+c doesn't work on some specific applications, such as
I noticed that when I boot to graphical login (runlevel 5) and log in and start
gnome-terminal ctrl+c doesn't work. It's a bit strange because ctrl+c works
correctly if I do for example "sudo tail -f file" but doesn't work with normal
user for example "tail -f file". Also if I boot to text login (runlevel 3) and
then startx, ctrl+c works correctly.
I have gnome-terminal-2.0.1-5 and vte-0.8.19-1.
When I start gnome from kdm the gnome-terminal fails to interrupt the foreground
process running in the terminal. Also I was not able to paste text from for
example mozilla window to gnome-terminal window.
When the gnome is started from gdm or with startx in runlevel 3 the
gnome-terminal works ok (the ctrl-c and paste work fine)
i've got the same strange behaviour.
RH 8.0, gnome-terminal-2.0.1-5, vte-0.8.19-1
if i run a gnome-terminal ctrl-c won't interrupt the foreground process.
(works with xterm and on the console).
now if i ssh to a remote RH8/7.x/6.x box from within the gnome-terminal, ctrl-c
appears to work for the remote shell.
even after ssh localhost, ctrl-c works again.
(ls -R / is good for testing this)
i've tested with a couple of installations now and i always get the same
behaviour. there is something broken, please have another look at it because
it's a pain to ctrl-z and kill % all the time (yes, ctrl-z works)
For what it is worth, I have this problem too. It shows up in several commands,
e.g. tail -f /var/log cannot be interrupted by ^c. This is somewhat annoying.
I have found a reliable way to trigger this bug at will.
I have a Sawfish shortcut <preferences:///Extras/Sawfish/Key Bindings> that maps
to Run shell command gnome-terminal. It doesn't matter which key.
(Unfortunately, the Xterm function doesn't pick up the value of the terminal
preference set in <preferences:///Extras/Preferred Applications>, so I need to
use Run shell command instead of Xterm. This seems to be a regression from the
previous version of Sawfish, which allowed you to specify what terminal Xterm
Starting from a GNOME session with no gnome-terminal running, if I start
gnome-terminal using a launcher on a panel, Ctrl-C works just fine. As long as
that instance of gnome-terminal is still running, all subsequent
gnome-terminals, whether launched via a launcher or my keyboard shortcut, work
However, if I exit all gnome-terminals, then start the first instance of
gnome-terminal using my keyboard shortcut, then Ctrl-C is broken in all
subsequent gnome-terminals, no matter how they are launched.
All of the instances of gnome-terminal seem to be sharing something with the
first instance of gnome-terminal, and there seems to be some difference in the
way launchers and Sawfish's Run shell command function work.
This behavior is observed even after upgrading vte-0.8.19-1 to the vte-0.8.19-2
Two possible workarounds are:
a) Always keep at least one "good" instance of gnome-terminal going (see above)
b) Hit Ctrl-Z, then kill %1 or whatever the job number is. Ctrl-Z always works.
For whatever reason, it works just fine in Red Hat 9, with sawfish and vte