xinitrc fails for some command

tinh · 2016-12-08 13:38:32

Hi,

I'm recreating a new environment from scratch
I have the following .xinitrc file where the line concerning .Xmodmap is not working.

[[ -L ~/.Xresources ]] && xrdb ~/.Xresources
[[ -L ~/.Xmodmap ]] && xmodmap ~/.Xmodmap

xscreensaver -no-splash &

exec i3

.Xmodmap file

clear lock
clear control
add control = Caps_Lock Control_L Control_R
keycode 66 = Control_L Caps_Lock NoSymbol NoSymbol

the ~/.Xmodmap is a symbolic link from dotfiles/.Xmodmap

What is strange is that executing this command in a terminal, after the X launch, works just fine.

x33a · 2016-12-08 17:35:50

What's the output of

type xmodmap

tinh · 2016-12-08 18:44:00

Hi thanks for the support, here's the output:

$ type xmodmap
xmodmap is /usr/bin/xmodmap

x33a · 2016-12-08 21:03:24

Hmm..., can you try passing the actual file to xmodmap instead of the symlink (in .xinitrc), like

xmodmap ~/dotfiles/.Xmodmap

seth · 2016-12-08 21:32:37

it's more likely that some i3 init script or i3 itself resets the configuration (try replacing it with eg. icewm to spot a difference)

tinh · 2016-12-09 20:02:02

x33a wrote:

Hmm..., can you try passing the actual file to xmodmap instead of the symlink (in .xinitrc), like
xmodmap ~/dotfiles/.Xmodmap

Sadly, It didn't fix the problem.

seth wrote:

it's more likely that some i3 init script or i3 itself resets the configuration (try replacing it with eg. icewm to spot a difference)

I tried using icewm, for instance, but it didn't fix the problem either.

WorMzy · 2016-12-09 20:06:23

Does it work without the conditional statement? What is the output of

stat ~/.Xmodmap

tinh · 2016-12-09 20:17:31

@WorMzy,

$ test -L .Xmodmap
$ echo $?
0
$ stat ~/.Xmodmap 
  File: '/home/tom/.Xmodmap' -> 'dotfiles/.Xmodmap'
  Size: 17        	Blocks: 0          IO Block: 4096   symbolic link
Device: 10303h/66307d	Inode: 332682      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/     tom)   Gid: ( 1000/     tom)
Access: 2016-12-09 20:22:25.506647388 +0100
Modify: 2016-12-06 16:46:22.084993780 +0100
Change: 2016-12-06 16:46:22.084993780 +0100
 Birth: -

what is very strange is that the previous line (concerning .Xresources & xrdb) is executed correctly.

Trilby · 2016-12-09 20:41:36

So, does it work without the conditional or not? You showed the `test` output in a shell where the command is already known to work, so that's not particularly helpful. Also, you use the bash builtin `[[` in xinitrc, so comparing to the standalone `test` binary also really isn't a great comparison.

If it works without the conditional in xinitrc, then the conditional is the problem. If it similarly fails without the conditional in the xinitrc, then Seth's suggestion is much more likely (and you should test that idea too).

tinh · 2016-12-09 21:14:11

Thanks for the explanations.

I tried, but again it doesn't work better without the conditional, either on i3 or icewm.

I started X with the following

$ cat .xinitrc 
#!/usr/bin/env bash

[[ -L ~/.Xresources ]] && xrdb ~/.Xresources
# [[ -L ~/.Xmodmap ]] && xmodmap ~/.Xmodmap
xmodmap ~/.Xmodmap

xscreensaver -no-splash &


# exec i3
exec icewm

Last edited by tinh (2016-12-09 21:16:02)

seth · 2016-12-09 21:29:57

#!/usr/bin/env bash

Why that?

I assume xrdb works as expected?
Tried to delay the modmap call?

(sleep 30; xmodmap ~/.Xmodmap) &

Trilby · 2016-12-09 23:01:43

xinitrc is sourced, not executed directly, so the shebang is irrelevant (it's just a comment). I like to start my xinitrc with "#!/bin/there /done/that"

seth · 2016-12-10 08:04:33

Could be relevant depending on whether he starts the xinitrc "command" when saying:
> What is strange is that executing this command in a terminal, after the X launch, works just fine.

If the modmap isn't simply reset (by some follow up setxkb or whatever) there still needs to be some difference in the invocation.
Wiring down some environment could be that difference.

Looking into all directions here ;-)

Trilby · 2016-12-10 12:51:40

Seth, I'm pretty sure the OP was saying the xmodmap comman works from a terminal within x. Trying to execute the xinitrc itself from within a terminal in X would have all sorts of other symptoms.

tinh · 2016-12-10 14:00:24

Yeah sorry for the confusing description. Trilby is right. I was talking about the command xmodmap not the entire .xinitrc file.

Just for curiosity I tried startx inside my terminal emulator, here's what I got (if someone interested):

$ startx

/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server
^C

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: unexpected signal 2
Couldn't get a file descriptor referring to the console

I'm kind a lost. What could possibly interfering with xmodmap that, in the meantime, doesn't affect the xrdb command?

Last edited by tinh (2016-12-10 14:00:46)

Trilby · 2016-12-10 14:02:12

Seth gave a likely answer and a way to test it in post #11.

tinh · 2016-12-11 11:42:08

Ok, Seth's solutions worked. Big thanks to you all!

May I ask why? Why did it work? And also what was the problem --Seth said that maybe i3 was resetting the config but I had the same problem with icewn--?

Trilby · 2016-12-11 12:49:42

That's not really a solution - it could be maintained as a poor workaround - but it's really just diagnostic.

The fact that it "worked" means something else is also changing the keymap during startup. Find out what that is, and disable it.

tinh · 2016-12-12 09:33:11

Alright, thanks. I'll keep you informed. Have you got any leads? If it helps, I just followed steps from here: https://wiki.archlinux.org/index.php/Xm … stom_table

Trilby · 2016-12-12 13:04:48

Do I have any leads on what software you've installed and configured and are running on your system? No.

tinh · 2016-12-12 14:06:21

Trilby, really glad you're so concerned about my issue. of course, I always thought you'd have such magical powers, and betwwen you and me, wondered why you didn't gave me THE answer at your first post.
Also, I didn't remember asking for such sarcastic and rhetorical question in return of mine.

May I ask you why on earth you spend your free time being a moron while I just tried to get over your sarcasms to spot an answer.

If you got any problem with me, can't you just keep me inform of it in PM and keep this topic free of your crap? If I'm doing something wrong I'd be glad to hear what you think because, obviously you seems to know more than me and can benefit from your wisdom (if any, afterall). Thanks again.

fsckd · 2016-12-12 14:42:32

tinh, please calm down. You've been around long enough to know the rules. Escalating like this is unnecessary.

Trilby · 2016-12-12 14:49:57

There was a bit of sarcasm in my post - but nothing of the level you respond with or seem to be reacting to. I was merely highlighting that you've not given any information with which anyone else could even start to help with this follow up question. something that you have installed, configured, and set to run at startup is changing your xmodmap settings. There are countless possibilities in the repos and AUR, and countless others you may have implemented yourself, so speculating on or listing all the possibilities would be futile.

In contrast, you *should* know what is installed and running on your system. So why don't you take the first steps instead of expecting everyone else to do your thinking for you? Describe your set up. What are you running? What WM, DE, user services, etc. If you provide all that information, someone here may help you. That someone will not be me though. I don't need to be abused for offering guidance. Good luck finding helpers who are interested in such gratitude.

seth · 2016-12-12 15:13:17

I'd start by testing whether all of xmodmap is reset or just concerning the caps lock stuff, eg. try swapping m & n or something.
And then simply get anything out of the way that occurs at system startup, starting w/ the other calls in initrc - and whether that is called by startx or xdm will certainly matter.
Also dump the keymap and inputs with xinitrc and the deferred xmodmap call again (for comparism)

And, off topic, get used to snippy answers to "what could be the problem" style questions - arch isn't ubuntu (jaja "respect other distros"... ;-).
A certain level is expected and you might get reminded of that. That's not necessarily meant offensive but "social education"

tinh · 2016-12-16 16:37:22

I would like to apology to all for my reaction and personally to Trilby. I wasn't feeling right these day but it's not an excuse to yell at you like I did. Again very sorry.

I managed to breath a little and investigate my system like you told me to do.

And here's what I found:

I have a X configuration file which I use to apply a accented variant to my keyboard. Here's the file:

% cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
        Option "XkbModel" "pc105"
        Option "XkbVariant" "altgr-intl"
EndSection

And it's working well. I made a backup of it (in order to keep X from loading it at startup) and guess what... xmodmap was working just fine with the xinitrc file (the same I showed in the original post).

I didn't found out what or why the 00-keyboard.conf was conflicting with the xmodmap line but I managed to find a workaround by replacing

[[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmomap

by

setxkbmap -option caps:ctrl_modifier

What I would like to know, it's why it was conflicting ? Also, is my workaround is a valid one or just another trick?
finally, do I have to mark the post as [solved]?

Arch Linux

#1 2016-12-08 13:38:32

xinitrc fails for some command

#2 2016-12-08 17:35:50

Re: xinitrc fails for some command

#3 2016-12-08 18:44:00

Re: xinitrc fails for some command

#4 2016-12-08 21:03:24

Re: xinitrc fails for some command

#5 2016-12-08 21:32:37

Re: xinitrc fails for some command

#6 2016-12-09 20:02:02

Re: xinitrc fails for some command

#7 2016-12-09 20:06:23

Re: xinitrc fails for some command

#8 2016-12-09 20:17:31

Re: xinitrc fails for some command

#9 2016-12-09 20:41:36

Re: xinitrc fails for some command

#10 2016-12-09 21:14:11

Re: xinitrc fails for some command

#11 2016-12-09 21:29:57

Re: xinitrc fails for some command

#12 2016-12-09 23:01:43

Re: xinitrc fails for some command

#13 2016-12-10 08:04:33

Re: xinitrc fails for some command

#14 2016-12-10 12:51:40

Re: xinitrc fails for some command

#15 2016-12-10 14:00:24

Re: xinitrc fails for some command

#16 2016-12-10 14:02:12

Re: xinitrc fails for some command

#17 2016-12-11 11:42:08

Re: xinitrc fails for some command

#18 2016-12-11 12:49:42

Re: xinitrc fails for some command

#19 2016-12-12 09:33:11

Re: xinitrc fails for some command

#20 2016-12-12 13:04:48

Re: xinitrc fails for some command

#21 2016-12-12 14:06:21

Re: xinitrc fails for some command

#22 2016-12-12 14:42:32

Re: xinitrc fails for some command

#23 2016-12-12 14:49:57

Re: xinitrc fails for some command

#24 2016-12-12 15:13:17

Re: xinitrc fails for some command

#25 2016-12-16 16:37:22

Re: xinitrc fails for some command

Board footer