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.

4 Answers 4


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, 2013 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, 2013 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, 2013 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, 2013 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .