Bug 79414 - Control-C fails to interrupt foreground process
Summary: Control-C fails to interrupt foreground process
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vte
Version: 8.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2003-04-25 02:23:52 UTC
Embargoed:


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:
Always

Steps to Reproduce:
1. Launch gnome-terminal
2. In terminal, start a long-running interruptible process, such as
     ls -R /
   or
     xev
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
WORKSFORME

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
gnome-terminal-2.0.1-5

$ rpm -q vte
vte-0.8.19-1


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 
rpm.

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.

Brad


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
meant.)

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
0.10.25-1.


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