Environment Variable not passed
nemeth-it opened this issue · comments
It seems that this workflow ignores ( don't passes ) the local environment variables to the remote machine. If I open iTerm by hand and connect to the target host via ssh hostname the remote machine gets the local environment variables I declared to send via local ~/.ssh/config-file:
SendEnv RMATE_*
Works only if on the remote machine the variable-namespace was declared to be accepted in the /etc/ssh/sshd_config-file:
AcceptEnv LANG LC_* RMATE_*
But if I use this workflow, it seems that this is getting ignored.
Finally, if I access a host via workflow the printenv-command don't show the declared local variable on the remote machine.
This isn't something the workflow does or doesn't do. It simply creates an ssh:// URL and passes it off to macOS/the app you've configured.
The environment and connection are handled entirely by the app you have configured as the handler for ssh:// URLs (or the one you've specified in the workflow settings).
Your environmental variables are presumably not being passed to the server because iTerm opens the ssh connection directly instead of loading your shell first and then opening the connection.
I don't found a solution yet, so I've created an Stackoverflow-Question related to this topic.
One workaround is to set MOSH_CMD in the settings to ssh, and then open connections with "mosh" (i.e. with ⌥↩).
That way, the workflow will run a command in your shell, rather than opening a URL, so your dotfiles should get loaded first. (At least, it works that way on my machine.)
The workflow did originally have a way to run an ssh command instead of opening a URL, but I took it out because I didn't see the point of having both.
I'll put the option back in.
I've added a new SSH_CMD option. Set that to ssh, and your local configuration files should get loaded as expected.
Awesome work, thank you!