You are not logged in.
Hi, I was hoping you guys could help me. The thing is, I'm running Arch with Subtle WM and so far everything is going fine; I just have one annoying issue. Whenever I open a terminal, and try to abort a command with Control-C, nothing happens. Pressing Ctrl-C while idle does nothing either, it doesn't even print ^C on the terminal. It's quite frustrating, because now, whenever I want to cancel a command, I have to close the window. The only times the key combination does work, is when I launch the Terminal from Synapse. And before you ask, this happens with every different terminal I've tried, be it Gnome-Terminal, xterm, Terminator, rxvt, etc.
I would appreciate if you could help me... Thanks!
Last edited by Arachnid92 (2011-05-16 20:56:57)
Offline
Could the Ctlr+C key combination be mapped to something else in the WM? Can you try this from a different WM/DE or maybe even from one of the virtual consoles (Ctrl+Alt+F1)
If Ctrl+C works in virtual console or any other WM/DE, then it could be an issue with Subtle WM..
Offline
I had no problems with the terminal in GNOME, so I'm thinking you could be right. I'll check it out and report back.
Offline
After going through my subtle.rb configuration file, I didn't find any conflicts with Ctrl-C... And even if I had, I was thinking, it still doesn't explain why it works when I launch the terminal from Synapse, and not when I use a command to do it. Weird. Maybe I'm missing an argument?
Offline
At the bash prompt, does the key sequence Ctrl-v Ctrl-c display ^C?
Is there a difference between the outputs of 'stty -a' from a working terminal and a non-working terminal? It should show, for a working Ctrl-C, "intr = ^C".
Or perhaps there is a difference between the outputs of 'bind -v' from the different terminals? Note whether 'bind-tty-special-chars' is on or off.
You can check readline settings for an explicit binding of '^C' with 'bind -p | grep C-c'.
[15:14] ~ $ bind -p | grep C-c # No output - nothing there.
[15:14] ~ $ bind -p | grep C-y # Shows there are bindings for Ctrl-y.
"\C-y": yank
"\e\C-y": yank-nth-arg
Last edited by thisoldman (2011-05-08 19:30:02)
Offline
At the bash prompt, does the key sequence Ctrl-v Ctrl-c display ^C?
Is there a difference between the outputs of 'stty -a' from a working terminal and a non-working terminal? It should show, for a working Ctrl-C, "intr = ^C".
Or perhaps there is a difference between the outputs of 'bind -v' from the different terminals? Note whether 'bind-tty-special-chars' is on or off.
You can check readline settings for an explicit binding of '^C' with 'bind -p | grep C-c'.
[15:14] ~ $ bind -p | grep C-c # No output - nothing there. [15:14] ~ $ bind -p | grep C-y # Shows there are bindings for Ctrl-y. "\C-y": yank "\e\C-y": yank-nth-arg
I tried all of the commands, and could not find any difference between a working terminal and a "faulty" one... It's a really weird error, because I have no problem with root terminals, only with normal ones. And by the way, I tried everything again in GNOME, and now Ctrl-C doesn't work there either. So I'm guessing it's not a WM error. And also, I've discovered that it is not only Ctrl-C that isn't working, but Ctrl-Z and a lot of other key combinations as well.
Offline
I've come across this problem before, for me it was because I was using 2 different keyboard layouts.
If you do have 2 different keyboard layouts configured, and you're using the 2nd keyboard layout (as can be found in the keyboard layout GUI in gnome / whatever you use), then the Ctrl key sequences will only work if you are using the 1st keyboard layout (even if the active keyboard layout is the 2nd layout).
It's difficult to explain, so to fix it you'll need to:
Move your preferred keyboard layout to be at the top of the list in the keyboard layout options in your GUI of choice.
An example:
If I have USA Dvorak keyboard layout as being the 1st layout in the list, and USA as the 2nd layout in the list, but have USA as the current layout, then to send a Ctrl+C to the GUI terminal I would have to press "Ctrl + i" (an "i" in USA is "c" in USA Dvorak).
Hopefully this is the same problem that you're having, and hopefully it'll fix it for you.
Even better if the root of this bug is found and patched.
Last edited by Rhubarb (2011-05-09 05:57:08)
Work smart, not hard.
Offline
I've come across this problem before, for me it was because I was using 2 different keyboard layouts.
If you do have 2 different keyboard layouts configured, and you're using the 2nd keyboard layout (as can be found in the keyboard layout GUI in gnome / whatever you use), then the Ctrl key sequences will only work if you are using the 1st keyboard layout (even if the active keyboard layout is the 2nd layout).
It's difficult to explain, so to fix it you'll need to:
Move your preferred keyboard layout to be at the top of the list in the keyboard layout options in your GUI of choice.An example:
If I have USA Dvorak keyboard layout as being the 1st layout in the list, and USA as the 2nd layout in the list, but have USA as the current layout, then to send a Ctrl+C to the GUI terminal I would have to press "Ctrl + i" (an "i" in USA is "c" in USA Dvorak).Hopefully this is the same problem that you're having, and hopefully it'll fix it for you.
Even better if the root of this bug is found and patched.
I thought it might be what you suggest, but after checking out all my settings, I couldn't find any conflicting layouts. But I did try removing the SetXKbmap option from my xorg config, and setting the keymap using rc.conf and mkinitcpio.conf instead. Didn't change a thing... Still, now I'm going to try reverting all keyboard changes to default, and see if that helps. I'll report back in a while.
EDIT: Nope, even with default keymap options, ^C does not work in GUI. I say GUI, because everything works excellent in my TTY's.
Last edited by Arachnid92 (2011-05-10 01:10:41)
Offline
Thinking it could really be a WM issue, I installed Openbox and ran a terminal in there. It doesn't work either. I still find it very strange that when I launch xterm through Synapse, ^C works great, but when I launch it from another terminal, or with a key combination, it doesn't work. WEIRD.
Offline
Any ideas? Before I revert back to Ubuntu?? (just joking xD) Seriously though, I don't want to have to format my PC just to get Ctrl-C working.
Offline
Does the command 'locale' show the same setting values in both good and bad terminals?
How about these:
$ echo $TERM
xterm-256color
$ echo $XTERM_LOCALE
en_US.UTF-8
$ echo $XTERM_SHELL
/bin/bash
It might be useful to compare other environment settings:
$ env | sort > goodenv # From good xterm
$ env | sort > badenv # From bad xterm
$ vimdiff goodenv badenv # Or use any other 'diff' program to compare the outputs.
Offline
Does the command 'locale' show the same setting values in both good and bad terminals?
How about these:
$ echo $TERM xterm-256color $ echo $XTERM_LOCALE en_US.UTF-8 $ echo $XTERM_SHELL /bin/bash
It might be useful to compare other environment settings:
$ env | sort > goodenv # From good xterm $ env | sort > badenv # From bad xterm $ vimdiff goodenv badenv # Or use any other 'diff' program to compare the outputs.
Hmm, this is weird... Here's my comparison between a good and a bad terminal:
Bad:
[arachnid92@arachnid92arch ~]$ echo $XTERM_LOCALE
[arachnid92@arachnid92arch ~]$ echo $XTERM
[arachnid92@arachnid92arch ~]$ echo $XTERM_SHELL
[arachnid92@arachnid92arch ~]$
Good:
[arachnid92@arachnid92arch ~]$ echo $XTERM_LOCALE
en_GB.utf8
[arachnid92@arachnid92arch ~]$ echo $XTERM
[arachnid92@arachnid92arch ~]$ echo $XTERM_SHELL
[arachnid92@arachnid92arch ~]$
So, they are pretty much the same, except for the locale.
Anyway, here are my Env Variables.
Bad:
COLORTERM=gnome-terminal
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-1CFKmBu3kT,guid=31f1162b7b8110b9933758a900000038
DESKTOP_SESSION=Subtle
DISPLAY=:0
G_BROKEN_FILENAMES=1
GDM_LANG=en_GB.utf8
GDMSESSION=Subtle
GNOME_KEYRING_CONTROL=/tmp/keyring-2SmfB3
GNOME_KEYRING_PID=2066
GTK_MODULES=canberra-gtk-module
HG=/usr/bin/hg
HOME=/home/arachnid92
J2REDIR=/usr/lib/jvm/java-6-openjdk/jre
J2SDKDIR=/usr/lib/jvm/java-6-openjdk
JAVA_HOME=/usr/lib/jvm/java-6-openjdk
LANG=en_GB.utf8
LOGNAME=arachnid92
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
ORBIT_SOCKETDIR=/tmp/orbit-arachnid92
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/vendor_perl:/usr/bin/core_perl:/opt/qt/bin
PKG_CONFIG_PATH=:/opt/qt/lib/pkgconfig
PWD=/home/arachnid92
QTDIR=/opt/qt
QT_XFT=true
SHELL=/bin/bash
SHLVL=2
SSH_AGENT_PID=2116
SSH_AUTH_SOCK=/tmp/ssh-zQnwPQPi2085/agent.2085
TERM=xterm
USER=arachnid92
USERNAME=arachnid92
_=/usr/bin/env
WINDOWID=39845921
WINDOWPATH=7
XAUTHORITY=/var/run/gdm/auth-for-arachnid92-v6v3EV/database
XDG_CACHE_HOME=/home/arachnid92/.cache
XDG_CONFIG_DIRS=/etc/xdg
XDG_CONFIG_HOME=/home/arachnid92/.config
XDG_DATA_DIRS=/usr/share/:/usr/local/share/
XDG_DATA_HOME=/home/arachnid92/.local/share
XDG_SESSION_COOKIE=cd05e17d6bb01652e75b34b8000008e1-1305072806.869649-469703727
GOOD:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-1CFKmBu3kT,guid=31f1162b7b8110b9933758a900000038
DESKTOP_SESSION=Subtle
DISPLAY=:0
G_BROKEN_FILENAMES=1
GDM_LANG=en_GB.utf8
GDMSESSION=Subtle
GNOME_KEYRING_CONTROL=/tmp/keyring-2SmfB3
GNOME_KEYRING_PID=2066
GTK_MODULES=canberra-gtk-module
HG=/usr/bin/hg
HOME=/home/arachnid92
IBUS_NO_SNOOPER_APPS=synapse
J2REDIR=/usr/lib/jvm/java-6-openjdk/jre
J2SDKDIR=/usr/lib/jvm/java-6-openjdk
JAVA_HOME=/usr/lib/jvm/java-6-openjdk
LANG=en_GB.utf8
LOGNAME=arachnid92
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/vendor_perl:/usr/bin/core_perl:/opt/qt/bin
PKG_CONFIG_PATH=:/opt/qt/lib/pkgconfig
PWD=/home/arachnid92
QTDIR=/opt/qt
QT_XFT=true
SHELL=/bin/bash
SHLVL=1
SSH_AGENT_PID=2116
SSH_AUTH_SOCK=/tmp/ssh-zQnwPQPi2085/agent.2085
TERM=xterm
USER=arachnid92
USERNAME=arachnid92
_=/usr/bin/env
WINDOWID=35651597
WINDOWPATH=7
XAUTHORITY=/var/run/gdm/auth-for-arachnid92-v6v3EV/database
XDG_CACHE_HOME=/home/arachnid92/.cache
XDG_CONFIG_DIRS=/etc/xdg
XDG_CONFIG_HOME=/home/arachnid92/.config
XDG_DATA_DIRS=/usr/share/:/usr/local/share/
XDG_DATA_HOME=/home/arachnid92/.local/share
XDG_SESSION_COOKIE=cd05e17d6bb01652e75b34b8000008e1-1305072806.869649-469703727
XTERM_LOCALE=en_GB.utf8
XTERM_SHELL=/bin/bash
XTERM_VERSION=XTerm(269)
Offline
It is odd. And a solution doesn't seem easy to find since documentation for terminal apps isn't always the best. But it is obvious that xterm is not setting some environment variables when called through different methods.
I do remember that some odd problems show up if the 'LOCALE=' isn't set properly in '/etc/rc.conf'. The capitalization in that line must match exactly the capitalization used in '/etc/locale.gen'.
I noticed that for you, 'LANG=en_GB.utf8'. My 'locale.gen' has the locales listed as "en_GB.UTF-8 UTF-8" and "en_GB ISO-8859-1".
Last edited by thisoldman (2011-05-11 11:08:13)
Offline
It is odd. And a solution doesn't seem easy to find since documentation for terminal apps isn't always the best. But it is obvious that xterm is not setting some environment variables when called through different methods.
I do remember that some odd problems show up if the 'LOCALE=' isn't set properly in '/etc/rc.conf'. The capitalization in that line must match exactly the capitalization used in '/etc/locale.gen'.
I noticed that for you, 'LANG=en_GB.utf8'. My 'locale.gen' has the locales listed as "en_GB.UTF-8 UTF-8" and "en_GB ISO-8859-1".
Ok, I'll check that out (the locale) and report back as soon as possible.
EDIT: Strangely enough, the locale is set as en_GB.UTF-8 in rc.conf. Should it have the second UTF-8 after it as well?
Last edited by Arachnid92 (2011-05-11 14:58:39)
Offline
I don't know if the second 'UTF-8' is recommended in '/etc/rc.conf'. I do not have it but my locale is "en_US.UTF-8", which is usually trouble-free.
Do you have DAEMON_LOCALE set to "yes" in 'rc.conf'? I don't believe this should make any difference, but mine is set to "yes".
The only other two locale related items I can think to suggest are straight from the wiki, Archwiki: Locale. I don't know if either of these will work –
Update the locale settings by running 'locale-gen' as root.
Try putting 'export LANG=en_GB.UTF8' in your '~./bashrc'.
I installed gnome-terminal to see if that interfered with '^C' on my machine; it does not interfere.
The xterm settings in my '~/.Xdefaults that might have some bearing on '^C' include:
XTerm*utf8: 2
XTerm*eightBitInput: false
XTerm*loginShell: true
I'm truly puzzled about your problem.
Offline
Dammit... Did everything you proposed, yet nothing seems to work. It's a very strange problem...
Offline
After doing some research, it seems it's possible that there is a backgrounded script running or a 'trap' is set for '^C' in a script or config file.
Ctrl-C entered at a blank bash prompt, when Ctrl-C works, creates a new line and presents another bash prompt. With 'intr' set to "", the bash cursor remains on the same line, without advancing.
With intr set to "", Ctrl-C does not work.
With 'Ctrl-C' working:
$ stty intr '^C' # The literal characters: circumflex or ^, and then Shift-C.
$
$ # Ctrl-C was pressed while the cursor was on the line above and advanced the cursor to this line.
$ # Ctrl-C will stop the next command immediately.
$ ping -c 6 www.google.com
PING www.l.google.com (74.125.91.103) 56(84) bytes of data.
--- www.l.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
With 'Ctrl-C' disabled:
$ stty intr ''
$ # Ctrl-C just leaves the cursor on this line.
$ # What Ctrl-C, or any keypress, does to a ping command is erratic,
$ # but the command carries through to the end.
$ ping -c 6 www.google.com
PING www.l.google.com (74.125.91.104) 56(84) bytes of data.
64 bytes from qy-in-f104.1e100.net (74.125.91.104): icmp_req=2 ttl=52 time=26.2 ms
64 bytes from qy-in-f104.1e100.net (74.125.91.104): icmp_req=3 ttl=52 time=28.4 ms
64 bytes from qy-in-f104.1e100.net (74.125.91.104): icmp_req=4 ttl=52 time=27.0 ms
64 bytes from qy-in-f104.1e100.net (74.125.91.104): icmp_req=6 ttl=52 time=26.1 ms
--- www.l.google.com ping statistics ---
6 packets transmitted, 4 received, 33% packet loss, time 5003ms
rtt min/avg/max/mdev = 26.192/26.975/28.437/0.922 ms
$ # pings 1 and 5 were lost.
I suggest you set 'intr' to Ctrl-C with the 'stty' command. Then try 'Ctrl-C'.
Also try the command 'trap', with no arguments. If 'trap' returns 'SIGINT' or '^C', you will have to find the program that is setting the trap.
The easiest to understand explanation of 'trap' that I have found is at http://bash.cyberciti.biz/guide/Trap_statement.
Offline
Trap output from a bad terminal:
[arachnid92@arachnid92arch ~]$ trap
trap -- '' SIGQUIT
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
[arachnid92@arachnid92arch ~]$
From a good terminal:
[arachnid92@arachnid92arch ~]$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
[arachnid92@arachnid92arch ~]$
The trap -- '' SIGQUIT command is missing from the good one... Could this have something to do with the problem?
Also, using stty to set ^C didn't change anything
Last edited by Arachnid92 (2011-05-13 14:50:59)
Offline
Decided I'm going to reinstall everything. I had to do it anyway, but this gave me an excuse to do it. xD I'll report back as soon as I'm done
Offline
I can understand the feeling that a new install might be easier than fixing all the annoyances.
Offline
Yepp... After booting up after reinstalling the system, I installed subtle as my window manager, and logged in... Guess what, as soon as I opened a terminal, ^C didn't work. Turns out it was a WM issue after all, which is REALLY weird, since I ruled that out in the beginning by trying other WMs (and none of them worked). But now, I removed subtle and I'm running WMFS... Everything good so far Thank you for your help, thisoldman!
Offline
Pretty old post, but I didn't noticed it until someone with the same problem pointed me to it. As the author of subtle I am aware of that bug with bash, but have neither an explanation nor a solution. I was never able to reproduce it myself and it doesn't happen in other shells like zsh at all.
Technically, subtle cannot trap that signal, since the terminal is a different process and there is no implicit grab on ^C.
Offline
Thought I'd reply on this thread to keep stuff about this bug in the same place.
So...
The problem is that applications don't respond to Ctrl-C in the terminal. Eg. ping - ^C gets printed on the screen but it has no effect.
The problem happens when bash is the login shell and subtle is running. When zsh is the login shell and I launch bash from a terminal everything works as it should. When I start openbox on another vt (I use cdm by the way) whilst subtle is running and bash is the default login shell - same problem. If I shut down subtle then flick back to the same instance of openbox and test again, Ctrl-C works as it should.
My xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
Option "BlankTime" "10"
Option "OffTime" "10"
EndSection
Section "Files"
ModulePath "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/misc"
FontPath "/usr/share/fonts/100dpi:unscaled"
FontPath "/usr/share/fonts/75dpi:unscaled"
FontPath "/usr/share/fonts/TTF"
FontPath "/usr/share/fonts/Type1"
FontPath "/usr/share/fonts/local"
FontPath "/usr/share/fonts/OTF"
FontPath "/usr/share/fonts/artwiz-fonts"
EndSection
Section "Module"
Load "record"
Load "dri"
Load "dri2"
Load "glx"
Load "dbe"
Load "extmod"
Load "drm"
EndSection
Section "ServerFlags"
Option "DontZap" "false"
Option "Composite" "enable"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mouse1"
#Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection
Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "XkbLayout" "gb"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
Option "dpms" "true"
EndSection
Section "Device"
Identifier "Card0"
Driver "radeon"
VendorName "ATI Technologies Inc"
BoardName "Radeon Mobility M6 LY"
BusID "PCI:1:0:0"
Option "AGPMode" "4"
Option "AGPFastWrite" "on" #Faster than default (off)
Option "SWcursor" "off" #Faster than default (on)
Option "EnablePageFlip" "on" #Faster than default (off)
Option "AccelMethod" "EXA" # or XAA, EXA, XAA more stable, XAA is deafult
Option "DynamicClocks" "on"
Option "BIOSHotkeys" "on"
Option "AGPSize" "32" # default: 8
Option "EnableDepthMoves" "true"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
# Virtual 2048 768
EndSubSection
EndSection
I use xinit through cdm to launch x - here is my .xinitrc:
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
# exec gnome-session
# exec startkde
xset b off
/home/tom/bin/tposd
cp ~/.gtkrc-2.0.normal ~/.gtkrc-2.0
setxkbmap gb
xmodmap ~/.Xmodmap
case $1 in
xterm)
exec ck-launch-session xterm
;;
vnc)
exec ck-launch-session vncviewer -fullscreen
;;
icewm)
icewmbg&exec ck-launch-session icewm
;;
openbox)
cp ~/.gtkrc-2.0.ob ~/.gtkrc-2.0&&exec ck-launch-session openbox-session
;;
lxde)
exec ck-launch-session startlxde
;;
subtle)
exec ck-launch-session subtle
;;
awesome)
wicd-gtk&exec ck-launch-session awesome
;;
*)
exec ck-launch-session subtle
;;
esac
And I use xmodmap to set AltGr to mod4. .Xmodmap:
clear mod5
add mod4 = ISO_Level3_Shift
Versions of everything that might be relevant:
local/bash 4.2.020-1
local/rxvt-unicode-no-resizeinc 9.12-1
local/subtle-hg 3165-1 (had the same issue with subtle from the repositories as well)
local/xorg-xmodmap 1.0.5-2
If there's anything else you'd like, let me know.
Thanks a lot
Offline
[Semi-Solved]
r u kidding?
mods.allow that joke?
Last edited by 1archgamenon2 (2012-01-05 15:54:30)
Offline
Trap output from a bad terminal:
[arachnid92@arachnid92arch ~]$ trap trap -- '' SIGQUIT trap -- '' SIGTSTP trap -- '' SIGTTIN trap -- '' SIGTTOU [arachnid92@arachnid92arch ~]$
You should not trap CTRL-C when using screen
Add this to your .profile
trap 3
I hope this will help someone else as the post is quite old...
Laurent
Offline