Please describe the problem.
git annex specifies its own socket path via -S. To overload with our socket path (to be reused by annex and other ssh invocations) we need to provide the path via annex-ssh-options option. And we cannot pass it as an overload -o ControlPath since -S specification provided by annex "overrides" it. The difficulty comes in possibly not quite common but still possible case when path to the socket contains a space. I have tried all kinds of possible specifications but failed to find one which works...
Could you give me a hint!? ;)
What version of git-annex are you using? On what operating system?
6.20170307+gitg24ade8a25-1~ndall+1
Please provide any additional information below.
# so -- ssh works
$> ssh -O check -oControlMaster=auto -S"/tmp/te st/socket" 'yohtest@smaug'
Master running (pid=20336)
# but can't get annex to use it:
$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto -S"/tmp/te st/socket"'
init ssh: Could not resolve hostname st/socket": Name or service not known
yohtest@smaug's password:
$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto "-S\"/tmp/te st/socket\""'
init ssh: Could not resolve hostname "-s\\"/tmp/te: Name or service not known
yohtest@smaug's password:
# etc
You can't accomplish this with
remote.<name>.annex-ssh-options, since it is not exposed to the shell, and the parser just breaks it up into words.A smarter parser would be needed. Or you could configure it in ~/.ssh/config, or perhaps make a ssh config file elsewhere and use annex-ssh-options to pass -F to ssh to make it use this other config file.
Now that git-annex supports
GIT_SSH_COMMAND, which is exposed to the shell, you should be able to accomplish it that way. I don't know if that would work in your use case, since the environment variable affects all ssh remotes, not just one.Is this still something you need, or does
GIT_SSH_COMMANDcover the use case?The missing case would be, if you need remote.name.annex-ssh-options, to pass the options only to that one remote and not others.
I don't feel it would be a good idea for git-annex to try to parse quoted options, etc. It would need to expose the config to the shell, the same way it implements GIT_SSH_COMMAND`, by wrapping the original command in "sh -c".
That would need to be a different config than ssh-options, because existing ssh-options might be broken by the change. Eg, if it is set to something containing a "$", that would not be exposed to the shell currently.
So, while this is clearly a gap, I'd prefer to only implement a fix if it's actually needed. Since the bug report is 3 years old and I've not gotten a nudge, I'm guessing maybe not needed..