Bug 79414 - Control-C fails to interrupt foreground process
Summary: Control-C fails to interrupt foreground process
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vte
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-11 14:48 UTC by Derek Poon
Modified: 2018-12-17 13:41 UTC (History)
4 users (show)

Fixed In Version: 0.10.25-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-25 02:23:52 UTC

Attachments (Terms of Use)

Description Derek Poon 2002-12-11 14:48:39 UTC
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):

How reproducible:

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.

Additional info:

This problem has been alluded to in the comments of bug 75740: another user
complained that Control-C doesn't kill "tail -f".

Comment 1 Derek Poon 2002-12-11 14:55:10 UTC
Oddly, Control-C does interrupt the ping command, though.

Comment 2 Michael Lee Yohe 2002-12-11 15:23:03 UTC

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

Comment 3 Havoc Pennington 2002-12-13 23:24:33 UTC
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 

Comment 4 Sami Knuutinen 2002-12-30 11:17:44 UTC
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.

Comment 5 Sami Knuutinen 2003-01-02 00:51:37 UTC
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)

Comment 6 x 2003-01-18 16:51:08 UTC
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)

Comment 7 Brad Smith 2003-02-02 23:19:42 UTC
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.


Comment 8 Derek Poon 2003-03-03 18:44:37 UTC
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
just fine.

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
erratum package.

Comment 9 Derek Poon 2003-03-03 18:49:27 UTC
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.

Comment 10 Derek Poon 2003-04-25 02:23:52 UTC
For whatever reason, it works just fine in Red Hat 9, with sawfish and vte

Note You need to log in before you can comment on or make changes to this bug.