Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
Package: ncurses-base Version: 5.7+20090803-2 Severity: critical Justification: breaks unrelated software ctrl-c does no longer cause SIGINT. Debugging this issue: When I create a new xterm (or rxvt) as a fork from my windowmanager (awesome) the terminal shows the broken behaviour. I have still some xterms that are not affected open. Those were started in 2009. Using strace on both working and a broken xterm show that both send \3 to the terminal fd when I press ctrl-c. stty on a working xterm looks like: speed 38400 baud; line = 0; On a broken xterm it looks like: speed 38400 baud; line = 0; -brkint -imaxbel Using stty brkint imaxbel or stty sane does not solve the issue. Also stty intr ^C does not help. Starting a xterm from an working xterm results in a working xterm. Starting a xterm from a broken xterm results in a broken xterm. Starting a xterm, starting vim within it and then doing :!xtermCR produces a working xterm. Saving the environment of a working xterm, loading it in a broken xterm and then starting a new xterm results in a broken xterm. Do you have any other ideas for debugging the issue? If you feel that I have assigned the bug report to the wrong package, please reassign it to the correct package. Helmut -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.3 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ncurses-base depends on: ii libncurses5 5.7+20090803-2 shared libraries for terminal hand Other packages of interest: ii bash 4.1-1 The GNU Bourne Again SHell ii rxvt 1:2.6.4-14 VT102 terminal emulator for the X Window System ii xterm 253-1 X terminal emulator ncurses-base recommends no packages. ncurses-base suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
Am 10.02.2010 um 22:32 schrieb Helmut Grohne: Package: ncurses-base Version: 5.7+20090803-2 Severity: critical Justification: breaks unrelated software ctrl-c does no longer cause SIGINT. Debugging this issue: When I create a new xterm (or rxvt) as a fork from my windowmanager (awesome) the terminal shows the broken behaviour. I have still some xterms that are not affected open. Those were started in 2009. Before or after you upgraded ncurses-base? That package has not been touched for more than five months. Using strace on both working and a broken xterm show that both send \3 to the terminal fd when I press ctrl-c. stty on a working xterm looks like: speed 38400 baud; line = 0; On a broken xterm it looks like: speed 38400 baud; line = 0; -brkint -imaxbel Here it looks exactly the same as in your broken xterm, and ^C works fine anyway. Using stty brkint imaxbel or stty sane does not solve the issue. Also stty intr ^C does not help. stty sane should remove the -brkint -imaxbel. Does it? Starting a xterm from an working xterm results in a working xterm. Starting a xterm from a broken xterm results in a broken xterm. Starting a xterm, starting vim within it and then doing :!xtermCR produces a working xterm. Saving the environment of a working xterm, loading it in a broken xterm and then starting a new xterm results in a broken xterm. Do you have any other ideas for debugging the issue? Not really, but you could send the output of 'env' and 'xrdb -query | grep -i xterm'. Do you see any differences between working and broken xterms? If you feel that I have assigned the bug report to the wrong package, please reassign it to the correct package. I feel it is assigned to the wrong package, but I have no idea what the right package could be. Kernel: Linux 2.6.24.3 Ever thought of upgrading this two years old, totally unsupported kernel? Sven -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
Hi Sven, thanks for your very quick reply. On Wed, Feb 10, 2010 at 11:26:07PM +0100, Sven Joachim wrote: I have still some xterms that are not affected open. Those were started in 2009. Before or after you upgraded ncurses-base? That package has not been touched for more than five months. Unfortunately I don't have any idea when I started the last working xterm. But I probably restarted some xterm within the past four months, so we can assume that ncurses-base is not the causing package. On a broken xterm it looks like: speed 38400 baud; line = 0; -brkint -imaxbel Here it looks exactly the same as in your broken xterm, and ^C works fine anyway. Ok. This information is of no help then. Using stty brkint imaxbel or stty sane does not solve the issue. Also stty intr ^C does not help. stty sane should remove the -brkint -imaxbel. Does it? It does. Do you have any other ideas for debugging the issue? Not really, but you could send the output of 'env' and Uhm. I don't really like to show my complete environment. I therefore give a diff from working to broken: -SHLVL=5 +SHLVL=20 -WINDOWID=20971535 +WINDOWID=12582927 -XTERM_LOCALE=de_DE +XTERM_LOCALE=C Here are some variables that might be of interest: LANG=C LANGUAGE=C LC_CTYPE=de_DE (no other LC_* is set) TERM=xterm WINDOWPATH=7 XTERM_SHELL=/bin/bash XTERM_VERSION=XTerm(253) 'xrdb -query | grep -i xterm'. Do you see any differences between working and broken xterms? The xrdb -query | grep -i xterm command has no output at all for me. If you feel that I have assigned the bug report to the wrong package, please reassign it to the correct package. I feel it is assigned to the wrong package, but I have no idea what the right package could be. Actually I didn't feel it was the right package either. However packages like xterm, rxvt or bash seemed even more wrong. Kernel: Linux 2.6.24.3 Ever thought of upgrading this two years old, totally unsupported kernel? Yes, it is on my todo list for about a year. Unfortunately I really rely on that system (well I shouldn't be running testing then ;-). Additionally I experience bugs that cause data loss on reboots, so I avoid the latter as hard as possible. Helmut PS: I will be unable to read mail for the extended weekend starting in 14 hours. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
