Edit: I discovered, that this seems to be a bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129 - Any idea how to fix this by myself?

I just want to switch to urxvt, but I have a strange problem with my .Xresources. When I log in and start urxvt, everything is pink in pink and I get these error messages

urxvt: unable to parse color 'S_base0', using pink instead.
urxvt: unable to parse color 'S_base03', using pink instead.
...(repeated for all colors I defined)...
urxvt: unable to parse color 'S_base03', using pink instead.

However, once I ran xrdb ~/.Xresources, all newly opened urxvt's are fine and beautifully solarized. WAT?

My .Xresources: https://gist.github.com/iGEL/6880992 - I'm using Ubuntu 13.04 (64 bit), but installed the package rxvt-unicode-256color from Ubuntu 13.10 to get the current version of urxvt (9.18).

Edit: Notice that the colors are defined in the same file they are used. Maybe urxvt (or whatever is reading the .Xresources) can't parse and use the variables in the same run? Looks however like an odd idea.


Ok, I figured it out: You have to remove the -noccp option in line 42 of /usr/sbin/lightdm-session, which prevents xrdb to use the preprocessor I needed.


If ~/.Xresources are not processed with cpp when you login, you may want to save your original source as another name and rebuild ~/.Xresources every time you make changes.

I just wrote a tool to automate this process: https://github.com/dolmen/Xresources.edit/


Your ~/.Xresources does not get read in automatically.

I suppose in Ubuntu (at least that's the case in debian) the resource file read in during the start of your X session is .Xdefaults.

To not break anything that depends (perhaps) on ~/.Xresources, just make a symbolic link:

ln -s .Xresources ~/.Xdefaults

Start a new X session and the pink in pink should be gone.

  • That unfortunately didn't help, it's still pink. Also the .Xresources seems to be parsed, because the error messages originate from the .Xresources – iGEL Oct 8 '13 at 19:42
  • @iGEL: That's a pity. I had exactly the same phenomenon (pink in pink), and the symbolic link fixed it. Unfortunately I don't have a Ubuntu machine to do further testing. – mpy Oct 8 '13 at 19:59
  • @iGEL: Perhaps you can check, if your ~/.xinitrc contains a line similar to test -r $HOME/.Xdefaults && xrdb -I$HOME -merge $HOME/.Xdefaults – mpy Oct 8 '13 at 20:04
  • 1
    Thank you for your help, but after a little more googeling, I discovered that it seems to be a bug in Ubuntu :( bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129 - Sorry for not doing it properly before. – iGEL Oct 8 '13 at 21:09

Another option, less intrusive, instead of modifying /usr/sbin/lightdm-session is to change the X session wrapper. This is my /etc/lightdm/lightdm.conf for Ubuntu 12.04:


Note the last line, which executes X11 sessions with the original Debian wrapper /etc/X11/Xsession. It is a script very similar to /usr/sbin/lightdm-session but lets the /etc/X11/Xsession.d/30x11-common_xresources file do its thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.