Hi guys, I’m having a really hard time packaging a script that I assumed would have been extremely simple.
Here’s my snapcraft.yml:
summary: magically transport your vim config to remote servers
ViSSHous is a simple tool which helps you carry your vim profile everywhere across SSH sessions, by embedding your vim configuration within SSH itself.
command: inotifywait -e modify -e create $HOME/.vimrc; sh vissh
Can snap commands not access the $HOME directory?
My vissh commands wants to access the $HOME directory as well.
I am trying to distribute a simple shell script that should be executed any time the .vimrc file changes. This is very explicitly simple with systemd unit file, as well as homebrew, but I cannot find a way to make it work here.
I don’t think we have any alternatives at the moment.
One of the difficulties in exposing PathChanged and friends to snaps is answering the question “can the snap read the given path?”. At present, systemd unit files are generated on package install, and not influenced by plug/slot connections.
It would be pretty easy to allow watching paths under e.g. $SNAP_DATA and $SNAP_COMMON since they are always accessible to the snap. Watching paths whose access is granted by interfaces like home, removable-media, etc is more problematic.
Your inotifywait work around is easier to reason about because the watch is being performed from within the sandbox: by definition you’ll only be able to watch files you can see from there.
How can I get the $HOME context inside my shell script to be of the actual user?
Snap should have permissions to read it, but the problem is that snap is passing its own $HOME context to the script when it runs it, is there any way to override that?
Looks like $HOME/.vimrc is being translated to /root/snap/visshous/x1/.vimrc - even though snap should not have access to the personal-files interface and be able to see $HOME/.vimrc, as defined in my snapcraft.yml.
@ogra That is the point though, since my snap is a daemon process, snap by default creates it as a system service unit by default - which runs with root user context. What I really need is a user service unit, which will run out of userspace context. Is there any way to do this?