Stefan Beller wrote:
> On Mon, Oct 23, 2017 at 2:31 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>> 1. First, check whether $GIT_SSH supports OpenSSH options by running
>>
>> $GIT_SSH -G <options> <host>
>>
>> This returns status 0 and prints configuration in OpenSSH if it
>> recognizes all <options> and returns status 255 if it encounters
>> an unrecognized option. A wrapper script like
>>
>> exec ssh -- "$@"
>>
>> would fail with
>>
>> ssh: Could not resolve hostname -g: Name or service not known
>
> capital -G?
The actual error message uses lowercase (presumably they use tolower on
the hostname).
>> - if (variant == VARIANT_TORTOISEPLINK)
>> - argv_array_push(&conn->args, "-batch");
>> + detect.use_shell = conn->use_shell;
>
> Why do we have to use a shell for evaluation of this
> test balloon?
If the user set GIT_SSH_COMMAND instead of GIT_SSH then we need to run
it using a shell. The above line inherits the use_shell setting so it
ends up doing whatever conn would do.
[...]
>> + argv_array_push(&detect.args, "-G");
> ...
>> + variant = run_command(&detect) ? VARIANT_SIMPLE : VARIANT_SSH;
>
> What if we have a VARIANT_SIMPLE, that doesn't care about -G
> but just connects to the remote host (keeping the session open), do we need
> to kill it after some time to have run_command return eventually?
>
> Or can we give a command to be executed remotely (e.g. 'false') that
> we know returns quickly?
Since stdin is /dev/null, it would presumably return quickly. But I
also don't expect this kind of behavior from GIT_SSH commands. The
kinds I'd expect are
A. The repo case, which forwards to 'ssh' and supports all 'ssh'
flags
B. The travis-ci case, which expects a host and command and does
not accept any flags
C. More sophisticated wrappers that parse flags but still do not
handle -G
For case (A), the detection run would figure out that this accepts
OpenSSH options. Good.
For case (B), the detection run would figure out that this does not
accept OpenSSH options. Good.
For case (C), the detection run would think that this does not accept
OpenSSH options, when it accepts some. But I think that's the best we
can do for now. Longer term, we need to work with the author of such a
script to find out what kind of interface they want.
Thanks and hope that helps,
Jonathan
