On Mon, Sep 23, 2019 at 5:24 AM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>
> On Sun, Sep 22, 2019 at 11:17:59PM -0400, Jeffrey Walton wrote:
> > I need to spy the command line arguments being passed around, but I
> > have not been able to do so. 'git clone -verbose' is ineffective, and
> > -vvv is rejected as an unknown option.
> >
> > How do I see command line arguments passed to the program in core.sshcommand?
>
> Try
>
> GIT_TRACE=1 git <rest of the command>
Thanks.
I set GIT_TRACE=1 and enabled tracing on the tunnel.exe program. I
then set <path-to-public-key> to a non-existent file. No warnings, no
errors. Just a failed authentication. It looks like the tunnel.exe
program is the problem.
I did notice Git is not handling paths correctly on Windows. First, a
test program:
#include <iostream>
#include <sstream>
int main(int argc, char* argv[])
{
std::cout << "Test tunnel program v1.0" << std::endl;
for (int i=0; i<argc; ++i)
{
std::ostringstream oss;
oss << "Arg " << i+1 << ": " << "'" << argv[i] << "'" << std::endl;
std::cerr << oss.str();
}
return 5;
}
Compile:
>cl.exe /nologo /W4 /EHsc test_tunnel.cxx
test_tunnel.cxx
=====
(A) core.sshCommand:
sshcommand = "C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe"
Result:
$ GIT_TRACE=1 git clone ssh://jeffrey.walton@xxxxxxxxxxx:22480/main
...
Cloning into 'main'...
11:44:32.192382 run-command.c:663 trace: run_command: unset
GIT_DIR; 'C:\Users\Jeffrey Walton\Desktop\test_tunnel.exe' -p 22480
jeffrey.walton@xxxxxxxxxxx 'git-upload-pack '\''/main'\'''
C:\Users\Jeffrey Walton\Desktop\test_tunnel.exe: C:UsersJeffrey:
command not found
fatal: Could not read from remote repository.
=====
(B) core.sshCommand:
sshcommand = "C:\\\\Users\\\\Jeffrey Walton\\\\Desktop\\\\test_tunnel.exe"
Result:
$ GIT_TRACE=1 git clone ssh://jeffrey.walton@xxxxxxxxxxx:22480/main
...
Cloning into 'main'...
11:45:59.161132 run-command.c:663 trace: run_command: unset
GIT_DIR; 'C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe' -p
22480 jeffrey.walton@xxxxxxxxxxx 'git-upload-pack '\''/main'\'''
C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe: C:\Users\Jeffrey:
No such file or directory
fatal: Could not read from remote repository.
=====
(C) core.sshCommand:
sshcommand = "C:\\\\Users\\\\JEFFRE~1\\\\Desktop\\\\TEST_T~1.EXE"
Result:
$ GIT_TRACE=1 git clone ssh://jeffrey.walton@xxxxxxxxxxx:22480/main
...
Cloning into 'main'...
11:47:49.973632 run-command.c:663 trace: run_command: unset
GIT_DIR; 'C:\\Users\\JEFFRE~1\\Desktop\\TEST_T~1.EXE' -p 22480
jeffrey.walton@xxxxxxxxxxx 'git-upload-pack '\''/main'\'''
Arg 1: 'C:\Users\JEFFRE~1\Desktop\TEST_T~1.EXE'
Arg 2: '-p'
fArg 3: '22480'
atal: pArg 4: 'jeffrey.walton@xxxxxxxxxxx'
rotocol error:Arg 5: 'git-upload-pack '/main''
bad line length character: Test
=====
(A) is stripping quotes but they are needed for Windows long file
names. (A) also seems to be double-escaping slashes.
(B) is also stripping quotes. (B) works around the double-escaping slashes.
(C) works around stripping quotes by using short filenames. (C) also
works around the double-escaping slashes.
I did not find a git-path or git-filename man page. Most of this
appear undocumented (to me).
>From a usability point of view, Windows long filenames have been
around since at least 1995. This is how Windows users expect things to
work for the last couple of decades:
shcommand = "C:\Users\Jeffrey Walton\Desktop\test_tunnel.exe"
or
shcommand = "C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe"
In contrast, this would not need quotes:
shcommand = C:\Users\Jeff\Desktop\test_tunnel.exe
If there is extra work to be done, then I think the program should do
it, not the user. I believe Git should preserve the quotes in a long
filename.
A fallback is to call GetShortPathName, but it is an incomplete
remediation because short name aliases can be turned off. If short
filenames were disabled on my system then the workaround would not
work.
Jeff
