Can't hotload config file if it is a symlink

[eddy-22]

Great project! I'm on Mac OSX 10.11 and using skhd to control chunkwm.

If ~/.skhdrc is a symlink, then it can't hotload the config file, and I have to do brew services restart skhd to see the changes. If ~/.skhdrc is a regular file, hotloading works just fine.

[koekeishiya]

Will add support for this at some point. No ETA for now though.

[koekeishiya]

implemented support for symlinks on master.

[yurrriq]

This does not seem to work when the symlink is relative, e.g. as created by GNU Stow.

[koekeishiya]

What's the expected behaviour when the symlink is relative? We have to pass the absolutepath to the FSEvents API.

My first assumption would be that we just prepend getenv("HOME") to the path returned by the symlink resolver if it is a relative symlink(?). I've never used GNU Stow and I don't know how it works.

Edit:
I think we can just replace the call to readlink with realpath and it should resolve relative symlinks as well.

[yurrriq]

👍 to realpath, though I think in the GNU Stow case, prepending getenv("HOME") would work too. I'll try out your change and let you know how I fare. Thanks for the patch, and the project in general, and for chunkwm!

[yurrriq]

e616840 seems to enable hotloading only if ~/.skhdrc is a real file or an absolute symlink on startup of skhd. After that, I can swap it for the relative symlink and everything works great.

[JeanMertz]

Is hotloading still supported on latest macOS?

I've installed skhd using Brew, and have the service running. Inspecting the launchctl plist shows hotloading isn't disabled, but editing my config file still does not update the running daemon.

skhd --reload works as expected.

My config is symlinked to $XDG_CONFIG_HOME/skhd/skhdrc (the result is an absolute symlink). The directory is symlinked, not the file itself.

[koekeishiya]

Hotloading is still a thing yes. I have not tested having an actual file in a symlinked directory, so that is probably why it is not working for you. You can run skhd with the --verbose flag and it should print the path to the file it resolved for the hotloader.

[JeanMertz]

Thanks for the pointer @koekeishiya. I suspect you are right that this use-case is unsupported.

This is what it prints:

skhd: watching files for changes:
	/Users/jean/.config/skhd/skhdrc

The /Users/jean/.config/skhd directory is symlinked from somewhere else. That implies that it starts watching the wrong file. If I edit that file, the edits take place in the original file, so no system events are sent to indicate that /Users/jean/.config/skhd is updated.

[kcrwfrd]

Ran into this issue as well when I broke my .skhdrc up into multiple files.

I have my configuration tracked in a dotfiles repo:

~/.dotfiles/skhdrc/
~/.dotfiles/skhdrc/skhdrc
~/.dotfiles/skhdrc/window
~/.dotfiles/skhdrc/space
# ...

Symlinked like

ln -s ~/.dotfiles/skhdrc ~/.config/skhdrc