XResources didn't handle #define well

[Seth Arnold]

I recently copied some Solarized XResources into my ~/.Xresources file. I tested with usual xrdb -merge while testing until I was happy. Several days later I rebooted into the April 1 packages and had some error messages:

$ urxvt: unable to parse color 'S_base0', using pink instead.
urxvt: unable to parse color 'S_base02', using pink instead.
urxvt: unable to parse color 'S_red', using pink instead.
urxvt: unable to parse color 'S_green', using pink instead.
urxvt: unable to parse color 'S_yellow', using pink instead.
urxvt: unable to parse color 'S_blue', using pink instead.
urxvt: unable to parse color 'S_magenta', using pink instead.
urxvt: unable to parse color 'S_cyan', using pink instead.
urxvt: unable to parse color 'S_base2', using pink instead.
urxvt: unable to parse color 'S_base03', using pink instead.
urxvt: unable to parse color 'S_orange', using pink instead.
urxvt: unable to parse color 'S_base01', using pink instead.
urxvt: unable to parse color 'S_base00', using pink instead.
urxvt: unable to parse color 'S_base0', using pink instead.
urxvt: unable to parse color 'S_violet', using pink instead.
urxvt: unable to parse color 'S_base1', using pink instead.
urxvt: unable to parse color 'S_base3', using pink instead.
urxvt: unable to parse color 'S_base1', using pink instead.

To reproduce, you can add just the following lines to your ~/.Xresources:

#define S_base0 #839496
URxvt*foreground: S_base0

Restart Unity. Start a urxvt and watch the standard error of the terminal you used to start urxvt. Note the horrible pink.

Run xrdb -merge ~/.Xresources and then start another urxvt. Note no errors and no horrible pink.

Somehow, the Unity-started mechanism for reading the Xresources didn't properly handle the #define statements. Perhaps Unity accidentally used the -nocpp option to xrdb?

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: unity 6.12.0daily13.04.01-0ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4
Uname: Linux 3.8.0-15-generic x86_64
ApportVersion: 2.9.2-0ubuntu5
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
Date: Mon Apr 1 23:35:23 2013
InstallationDate: Installed on 2012-10-18 (166 days ago)
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
MarkForUpload: True
ProcEnviron:
 TERM=rxvt-unicode
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: Upgraded to raring on 2013-03-18 (15 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[iGEL (igel)]

I located to -nocpp option and created a separate bug: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578

[Stephen M. Webb (bregma)]

We don't usually open new bugs for the same problem, but in this case the new bug is properly targeted and the cause is better described.

[Seth Arnold (seth-arnold)]

iGEL, thanks for finding the real cause of the problem, now it might actually get fixed and I can drop one of my Unity workarounds. :)

[Olivier Mengué (dolmen)]

I think that cpp has been disabled for performance reasons.

@iGEL, as you are manually editing your .Xresources only once in a while it would be more efficient for session initialization to process your X ressources definitions through cpp just once after your editing.

So the workaround is:
   ( echo "! Do not edit .Xresources but .Xresources.def" ; echo "! Rebuild with cpp -P .Xresources.def .Xresources" ; cat .Xresources ) > .Xresources.def
Every time you want to change your X resources, edit .Xresources.def and then:
   cpp -P .Xresources.def .Xresources

[Olivier Mengué (dolmen)]

I just wrote a wrapper for your $EDITOR to edit your Xresources and process them through cpp.
Check https://github.com/dolmen/Xresources.edit