That's just it: you've told X that pressing 'a' should count as pressing 'XF86AudioMute', but neither Sawfish nor X is configured to do anything with it (except pass the keypress event to the active application). If, unlike mplayer, the application is not programmed to respond to XF86AudioMute ...
Mplayer recognizes some multimedia keys (like XF86AudioRaiseVolume) out of the box, but configuring them outside specific applications depends on the desktop environment you're using.
Personally, I use x11-misc/xbindkeys which is DE agnostic. In case you want to give it a try, here's a part of my ...
I'm not sure if removing python-exec would be safe. Is your system up-to-date? There was an eselect news item about python-exec package move and related blockers (2013-11-07-python-exec-package-move) that might be relevant.
I do have an iptables firewall up since at least 2012, and there's a built-in firewall in the router-ADSL modem combo from my ISP. Though I've made no changes to either around the time that problems started.
I'm not really privy to the inner workings of network protocols, but I do have an iptables ...
From the topic I'm assuming you want to set the keyboard layout in X. The settings in /etc/conf.d/keymap control layout in the console and have no bearing on X. I don't know if it's possible to use two layouts in the console; I'm guessing the later setting (sk-qwerty) from /etc/conf.d/keymap is in ...
It seems to me that $(TARGET) depends on file1.c via obj/file1.o, but obj/ file1.o may not depend on file1.h. At least this is the case if .depend contains, as I'm guessing, a line like
I've had a lot of problems syncing the portage tree since Oct 1, 2013. I've been using rsync.europe.gentoo.org or rsync.se.gentoo.org (I live in Finland) without problems prior to that date. Checking emerge.log between Oct 1 and the last sync before that, I found no changes to my system that appear ...
Once more about reading portage variables: I just noticed there's a tool that can do it (and more). So instead of sourcing make.conf to get PORT_LOGDIR (along with everything else), you could do portlogdir=`portageq envvar PORT_LOGDIR` which feels a tad better to me. Append 2>/dev/null within ...
If you want to do things cleanly, don't try to parse make.conf variables with sed like this: portlogdir=`cat /etc/make.conf | grep ^PORT_LOGDIR | sed 's/PORT_LOGDIR=//' | sed 's/\"//g' | sed 's/\/$//'` Just let bash parse it for you by adding as first line source /etc/make.conf and use PORT ...
Nothing besides permission problems springs to my mind when reading your description. You are in the games group, so next I would check that the permissions of the game executables and the high score files (and directory) are not b0rked. Mine look like this (I'll take gnomine as an example) -r-xr-s ...
I think the problem was that the user was not in the wheel group. It seems you are correct, although, as I tested it on my box the error message was different from csfsmash's. With user not in wheel I get this: $ su - Password: su: Permission denied Sorry.
Check what /bin/sh looks like by ls -l /bin/sh For me, the output looks like this lrwxrwxrwx 1 root root 4 Apr 16 21:37 /bin/sh -> bash which means that /bin/sh is a symlink pointing to /bin/bash. In this case, do the same thing for the link's target. In my case this is ls -l /bin/bash which ...
It looks like root's shell is set to /bin/sh in /etc/passwd, and the execute permission to /bin/sh (or to whatever it points to, if it's a symlink) is not set.
Can't say without some research why you have to hit enter to get back to vim. If I recall correctly though, I have to do it after every compile regardless. You could use pdflatex to do it in one go, unless you need the .dvi file.
Vim won't keep variables' values between sessions, so you'll have to set them in the files that vim sources on startup for the effect to be permanent. I guess the proper place in this case would be ~/.vim/ftplugin/tex/texrc.vim, depending on your environment of course. This works for me (stock ...
I'm not too familiar with genkernel, but SinoTech's first post has a logical explanation. I presume that this disappearance of changes does not occur when you're doing things 'by hand' as you described? The filename (or location to that matter) of the kernel image is, as mentioned, irrelevant as ...
What do you mean by settings disappearing? Is the new kernel not loaded on reboot or are the changes in /usr/src/linux/.config lost? Or am I completely off the map?
My understanding is that the state is saved on exit. So instead of playing with sed, why not put something like 'mpc stop' in the stop part of the script before the command that terminates mpd?
Ok, I did what I should have done right from the start. Read the man page of sed (and grep), that is :)
Apparently there are two kinds of regexps: basic and extended. Default for sed and grep is the former, in which characters like ? + ( | { lose their special meaning unless preceded by a ...
Silly me. It seems to work like I tought + would do alone (match one or more occurrences
of the previous block). I just don't understand why it has to be escaped. Back in the days,
at least Rute used to teach this the other way around.