https://wiki.archlinux.org/index.php/Co … bumping.22
https://wiki.archlinux.org/index.php/Co … mpty_posts
Closing.
]]>I had a similar problem, thanks thisoldman for pointing me in the "trap" direction.
So now I call trap - INT to clear the trap before leaving the function
]]>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
[Semi-Solved]
r u kidding?
mods.allow that joke?
]]>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
]]>Technically, subtle cannot trap that signal, since the terminal is a different process and there is no implicit grab on ^C.
]]>[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
]]>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.
]]>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.
]]>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?
]]>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".
]]>