Wrong color scheme in urxvtc after booting

kelnoky · 2014-07-15 09:36:15

I recently tried out several different color schemes for urxvt. I found a new, nice looking one, but ever since then the urxvtc window that is opened automatically from my .xinitrc will have a completely wrong color scheme. If I simply close it and open a new urxvtc, everything is fine. I do *not* need to 'xrdb -load ~/.Xresources' before starting this new terminal. So I have no idea what's wrong here.

This is my .xinitrc:

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

[[ -f ~/.Xress ]] && xrdb -load ~/.Xress


xset r rate 200 &
numlockx &
urxvtd &
setxkbmap -layout de -variant 'nodeadkeys' &
mpd
wallpaper.sh &
#mpdas &
setxkbmap -option terminate:ctrl_alt_bksp &
sleep 1s && firefox &
claws-mail &
#setxkbmap -option caps:super &
sleep 3s && urxvtc -name "weechat" -e screen weechat &
urxvtc -name "ncmpcpp" -e ncmpcpp &
skype &
sleep 1s && ps3mediaserver &
xsetroot -cursor_name left_ptr &
doublecmd &
transmission-gtk &
trayer --widthtype request --edge top --align right --SetDockType true --SetPartialStrut true &
xcompmgr -c &
steam &



exec xmonad
#exec openbox-session

I changed the name of the .Xresources file to .Xress to try and see if that can somehow be the problem, but it didn't help. The sleep 3s before I start the relevant urxvtc with weechat is because I thought it started to early for the .Xress settings to take effect. But apparently that's not the case. I also tried to delay urxvtd with sleep for the same reason. I just don't know how to fix this anymore, please help.

edit: this is my ~/.Xress that is read by my .xinitrc:

URxvt*background:  #000000
URxvt*foreground: #ffffff
URxvt*fading:   50
URxvt*tintColor: gray
URxvt*shading:   30
URxvt*transparent: false
URxvt*scrollBar: false
URxvt*title: URxvt!
URxvt*termName: rxvt-256color
URxvt*intensityStyles: true
URxvt*scrollTtyKeypress:    true
URxvt*scrollTtyOutput:      false
URxvt*scrollWithBuffer:     false
URxvt*cursorUnderline: true
URxvt*url-launcher: firefox
URxvt*perl-ext-common: default,matcher
URxvt.scrollstyle:      plain
URxvt.secondaryScroll:  true
URxvt*matcher.button:       1

!URxvt.font: xft:terminus:size=9
!URxvt.boldfont: xft:terminus:size=9

!URxvt.font: -*-terminus-medium-r-*-*-14-*-*-*-*-*-iso10646-1
!URxvt.boldFont: -*-terminus-bold-r-*-*-14-*-*-*-*-*-iso10646-1

!URxvt.font: -*-terminusmodx-medium-*-*-*-12-*-*-*-
!URxvt.boldfont: -*-terminusmod-medium-*-*-*-12-*-*-*-
!URxvt*font: -*-terminusmodx-medium-*-*-*-*-*-*-*-*-*-*-*
!URxvt*boldfont: -*-terminusmod-bold-*-*-*-*-*-*-*-*-*-*-

!URxvt*boldFont:xft:terminus:size=9:antialias=false:bold
!URxvt*font: xft:Liberation Mono:pixelsize=13:antialias=true:hinting=true

!URxvt*font: xft:Droid Sans Mono:pixelsize=12:antialias=true:hinting=true
!URxvt*boldFont: xft:Droid Sans Mono:bold:pixelsize=12:antialias=true:bold:hinting=true


URxvt*font: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:hinting=true
URxvt*boldFont: xft:DejaVu Sans Mono:bold:pixelsize=12:antialias=true:bold:hinting=true
!URxvt*italicFont: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:italic:autohint=true:hinting=true
!URxvt*bolditalicFont: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:bold:italic:autohint=true:hinting=true


xterm*font:              -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-*


urxvt*foreground: white
urxvt*background: black

urxvt*color0:  #2E3436
urxvt*color1:  #a40000
urxvt*color2:  #4E9A06
urxvt*color3:  #C4A000
urxvt*color4:  #3465A4
urxvt*color5:  #75507B
urxvt*color6:  #ce5c00
urxvt*color7:  #babdb9
urxvt*color8:  #555753
urxvt*color9:  #EF2929
urxvt*color10: #8AE234
urxvt*color11: #FCE94F
urxvt*color12: #729FCF
urxvt*color13: #AD7FA8
urxvt*color14: #fcaf3e
urxvt*color15: #EEEEEC


Xft.antialias: true
Xft.autohint: true
Xft.hinting: true
Xft.hintstyle: hintslight
Xft.rgba: rgb

Last edited by kelnoky (2014-07-15 09:37:27)

xero · 2014-07-15 15:15:57

i'm not familiar with the method you are using to source your .Xresources file.

i use this code before i start the urxvt daemon:

xrdb -merge "${HOME}/.Xresources"

Last edited by xero (2014-07-15 15:17:10)

Trilby · 2014-07-15 15:39:32

That looks like it should work, but there are a lot of moving parts in the xinitrc, so it is hard to tell what might be happening. If you want to figure out the mystery - find the simplest versions of xinitrc that do/don't work.

But for a much simpler approach, just use ~/.Xdefaults rather than Xresources (or Xress) as urxvt reads the first one itself.

kelnoky · 2014-07-15 20:01:05

The method of sourcing my .Xress is simply taken from the arch wiki page on X resources. Before these shenigangs started and I tried to troubleshoot myself I also had a simple "xrdb -merge ~/.Xresources &" in my .xinitrc. I deleted that and left the line I have now, cause I thought I would go with the arch wiki on this.

I don't have an ~/.Xdefaults because that file has been deprecated according to the arch wiki. Does urxvt still read .Xdefaults?

jasonwryan · 2014-07-15 20:09:22

How are you logging in? Are you using a DM?

kelnoky · 2014-07-15 22:45:44

I automatically login and automatically startx, no DM. I just followed these articles for that: https://wiki.archlinux.org/index.php/Au … al_console and https://wiki.archlinux.org/index.php/Start_X_at_Login

kelnoky · 2015-11-28 20:31:23

I have lived with this weird behaviour for a long time now. I am still baffled by it every time I boot up. Naturally, this is nothing that is too hard to deal with, I just need to close the teminal window and open a new one - still, I would like to fix this. Does anyone have any other ideas?

Trilby · 2015-11-28 21:34:21

kelnoky wrote:

Does urxvt still read .Xdefaults?

Yes.

kelnoky wrote:

Does anyone have any other ideas?

Have you tried my suggestion yet?

People can quibble all they want about what the standards say and what is deprecated and what should and should not work. But if you want to know what will work, try ~/.Xdefaults.

Head_on_a_Stick · 2015-11-28 21:46:30

kelnoky wrote:

Does urxvt still read .Xdefaults?

Not if there are any resources attached to the X server.

urxvt(7) wrote:

Why doesn't rxvt-unicode read my resources?
Well, why, indeed? It does, in a way very similar to other X
applications. Most importantly, this means that if you or your OS loads
resources into the X display (the right way to do it), rxvt-unicode
will ignore any resource files in your home directory. It will only
read $HOME/.Xdefaults when no resources are attached to the display.
If you have or use an $HOME/.Xresources file, chances are that
resources are loaded into your X-server. In this case, you have to re-
login after every change (or run xrdb -merge $HOME/.Xresources).

Last edited by Head_on_a_Stick (2015-11-28 21:46:49)

Trilby · 2015-11-28 21:48:37

The man page can say whatever it wants. That does not match what actually happens. Try it.

EDIT: evidence:

$ cat ~/.Xresources
URxvt*background: red

$ xrdb -load ~/.Xresources

$ strace urxvt 2>&1 | grep Xdefaults
open("/home/jmcclure/.Xdefaults", O_RDONLY) = 7
open("/home/jmcclure/.Xdefaults-Think", O_RDONLY) = -1 ENOENT (No such file or directory)

And my new urxvt window shows up with the dark background specified in the ~/.Xresources, *not* the red color specified in the x resource database.

Head_on_a_Stick · 2015-11-28 21:50:34

Trilby wrote:

The man page can say whatever it wants. That does not match what actually happens. Try it.

I have done -- I know about this 'cos my .Xdefaults wouldn't load in a desktop with a loaded ~/.Xresources file until I called `xrdb ~/.Xdefaults`

EDIT: I've just confirmed it -- if ~/.Xresources is created and loaded with xrdb(1) then ~/.Xdefaults is ignored by urxvt on subsequent startup.

Last edited by Head_on_a_Stick (2015-11-28 21:54:29)

Trilby · 2015-11-28 21:55:27

Then we have very very different experiences (see my edits). Why not let the OP try it and see if it works? Worst case, it doesn't. Best case, a months old annoyance goes away.

Why are people so hesitant to try simple solutions that work. It works on every system I've been on. I'm not saying it makes sense, nor that it should work - but it does (most of the time, apparently) so it seems like a good idea for the OP to try as nothing else is working.

Head_on_a_Stick · 2015-11-28 22:00:30

Trilby wrote:

EDIT: evidence:
$ cat ~/.Xresources
URxvt*background: red

$ xrdb -load ~/.Xresources

$ strace urxvt 2>&1 | grep Xdefaults
open("/home/jmcclure/.Xdefaults", O_RDONLY) = 7
open("/home/jmcclure/.Xdefaults-Think", O_RDONLY) = -1 ENOENT (No such file or directory)
And my new urxvt window shows up with the dark background specified in the ~/.Xresources, *not* the red color specified in the x resource database.

I think we're at cross purposes here.

My assertion is that if ~/.Xresources is present and the contents loaded to the display server then urxvt will *not* read ~/.Xdefaults when it starts up (this is what the man page says).

At any rate, you are quite correct -- let the OP try it.

Sorry for the noise.

Trilby · 2015-11-28 22:03:05

Head_on_a_Stick wrote:

My assertion is that if ~/.Xresources is present and the contents loaded to the display server then urxvt will *not* read ~/.Xdefaults when it starts up (this is what the man page says).

Did you see my strace. The man page is clearly wrong. The file was read. This is why I did the strace, so it wasn't some indirect inference from the resulting color of my terminal - strace caught the system call to read that very file.

kelnoky · 2015-11-29 08:38:01

What. The. Hell.

Ok, so for lack of any other option, I created an .Xdefaults. It is identical to my ~.Xress. I then did 'xrdb ~/.Xress' again, just to be sure, and restarted my PC. After the reboot, my terminal had the right colors from the first start, so yay! However, now the fucking font is black by default - just like the background, resulting in invisible ink... When I close that instance of urxvtc and open a new one, I get the right background and foreground colors, without having to xrdb anything. So basically I still have the same original problem, just with different colors now. This is beyond mystifying.

Screenshot of the autostarted instance of urxvtc with weechat: http://i.imgur.com/JO9NLN7.png (I have selected a portion of the text to show you there is actual text there)
Screenshot of the new instance of urxvtc, without doing anything: http://i.imgur.com/RJcvYfA.jpg

I don't get this.

My ~.Xress / ~.Xdefauls (they are identical, I have diffed it):

URxvt*fading:   30
URxvt*tintColor: gray
URxvt*shading:   10
URxvt*transparent: true
URxvt*scrollBar: false
URxvt*title: URxvt!
URxvt*termName: rxvt-256color
URxvt*intensityStyles: true
URxvt*scrollTtyKeypress:    true
URxvt*scrollTtyOutput:      false
URxvt*scrollWithBuffer:     false
URxvt*cursorUnderline: true
URxvt*url-launcher: firefox
URxvt*perl-ext-common: default,matcher
URxvt.scrollstyle:      plain
URxvt.secondaryScroll:  true
URxvt*matcher.button:       1

!URxvt.font: xft:terminus:size=10
!URxvt.boldfont: xft:terminus:size=10

!URxvt*font: xft:Droid Sans:pixelsize=10:antialias=true:hinting=true
!URxvt*boldFont: xft:Droid Sans:bold:pixelsize=10:antialias=true:bold:hinting=true

!URxvt.font: xft:Bitstream Vera Sans:size=9:antialias=true
!URxvt.boldFont: xft:Bitstream Vera Sans:bold:size=9:antialias=true

!URxvt*font: xft:Inconsolata:pixelsize=12:antialias=true:hinting=true
!URxvt*boldFont: xft:Inconsolata:bold:pixelsize=12:antialias=true:bold:hinting=true

URxvt*font: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:hinting=true
URxvt*boldFont: xft:DejaVu Sans Mono:bold:pixelsize=12:antialias=true:bold:hinting=true
!URxvt*italicFont: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:italic:autohint=true:hinting=true
!URxvt*bolditalicFont: xft:DejaVu Sans Mono:pixelsize=12:antialias=true:bold:italic:autohint=true:hinting=true


xterm*font:              -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-*

dzen2.font:       xft:DejaVu Sans Mono:pixelsize=12:antialias=true:hinting=true


urxvt*foreground: #F7FCF7
urxvt*background: #0A0A0A

!urxvt*color0:  #2E3436
!urxvt*color1:  #a40000
!urxvt*color2:  #4E9A06
!urxvt*color3:  #C4A000
!urxvt*color4:  #3465A4
!urxvt*color5:  #75507B
!urxvt*color6:  #ce5c00
!urxvt*color7:  #babdb9
!urxvt*color8:  #555753
!urxvt*color9:  #EF2929
!urxvt*color10: #8AE234
!urxvt*color11: #FCE94F
!urxvt*color12: #729FCF
!urxvt*color13: #AD7FA8
!urxvt*color14: #fcaf3e
!urxvt*color15: #EEEEEC

!black
*color0: #393939
*color8: #474747

!red
*color1: #da4939
*color9: #ff6c5c

!green
*color2 : #9acc79
*color10: #8fb676

!yellow
*color3:  #d0d26b
*color11: #c8bc45

!blue
*color4:  #597D9E
*color12: #758ba3

!magenta
*color5: #9f5079
*color13: #a761c2

!cyan
*color6: #435d75
*color14: #6e98a4

!white
*color7: #c2c2c2
*color15: #c2c2c2

Xft.antialias: true
Xft.autohint: true
Xft.hinting: true
Xft.hintstyle: hintmedium
Xft.rgba: rgb

I don't know what's going on anymore. I edited both my .Xress and .Xdefaults by adding these two lines to the top:
URxvt*foreground: #F7FCF7
URxvt*background: #0A0A0A

Same colors, just at the top of the file and with capital U and R. This should not make a difference whatsoever. I saved the files, rebooted and got all the right colors from the start. I guess this is "solved", if you can call it that...

Last edited by kelnoky (2015-11-29 08:47:07)

Trilby · 2015-11-29 13:21:47

kelnoky wrote:

Same colors, just at the top of the file and with capital U and R. This should not make a difference whatsoever.

Yes it should. Class selectors are case sensitive. This was going to be my comment when I read your XDefaults file that you posted.

Arch Linux

#1 2014-07-15 09:36:15

Wrong color scheme in urxvtc after booting

#2 2014-07-15 15:15:57

Re: Wrong color scheme in urxvtc after booting

#3 2014-07-15 15:39:32

Re: Wrong color scheme in urxvtc after booting

#4 2014-07-15 20:01:05

Re: Wrong color scheme in urxvtc after booting

#5 2014-07-15 20:09:22

Re: Wrong color scheme in urxvtc after booting

#6 2014-07-15 22:45:44

Re: Wrong color scheme in urxvtc after booting

#7 2015-11-28 20:31:23

Re: Wrong color scheme in urxvtc after booting

#8 2015-11-28 21:34:21

Re: Wrong color scheme in urxvtc after booting

#9 2015-11-28 21:46:30

Re: Wrong color scheme in urxvtc after booting

#10 2015-11-28 21:48:37

Re: Wrong color scheme in urxvtc after booting

#11 2015-11-28 21:50:34

Re: Wrong color scheme in urxvtc after booting

#12 2015-11-28 21:55:27

Re: Wrong color scheme in urxvtc after booting

#13 2015-11-28 22:00:30

Re: Wrong color scheme in urxvtc after booting

#14 2015-11-28 22:03:05

Re: Wrong color scheme in urxvtc after booting

#15 2015-11-29 08:38:01

Re: Wrong color scheme in urxvtc after booting

#16 2015-11-29 13:21:47

Re: Wrong color scheme in urxvtc after booting

Board footer