git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* How to see command line arguments passed to program in core.sshcommand?
@ 2019-09-23  3:17 Jeffrey Walton
  2019-09-23  9:24 ` SZEDER Gábor
  2019-09-24 17:12 ` Derrick Stolee
  0 siblings, 2 replies; 5+ messages in thread
From: Jeffrey Walton @ 2019-09-23  3:17 UTC (permalink / raw)
  To: Git List

Hi Everyone,

I'm working in an unusual setup on WIndows. I need to 'git clone' over
SSH, but a third party program has to handle the tunnel. It happens by
using this git configuration:

    git config --global core.sshcommand "tunnel.exe ... <path-to-public-key>"

After I execute the 'git config' command, I open ~/.gitconfig and
ensure the path is correct and quoted per Windows standards.

So far the result has been a failed authentication, which seems to
indicate something went sideways using the public key. I don't receive
an error from Git or or the tunnel program relating to a "file not
found" (or any errors for that matter until authentication fails).

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?

Thanks in advance.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: How to see command line arguments passed to program in core.sshcommand?
  2019-09-23  3:17 How to see command line arguments passed to program in core.sshcommand? Jeffrey Walton
@ 2019-09-23  9:24 ` SZEDER Gábor
  2019-09-23 17:18   ` Jeffrey Walton
  2019-09-24 17:12 ` Derrick Stolee
  1 sibling, 1 reply; 5+ messages in thread
From: SZEDER Gábor @ 2019-09-23  9:24 UTC (permalink / raw)
  To: Jeffrey Walton; +Cc: Git List

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>

and, among other things, you'll see something like

  11:20:12.013785 run-command.c:663       trace: run_command: unset GIT_PREFIX; ssh git@github.com 'git-receive-pack '\''/szeder/git'\'''

in its output (this was for a 'git push').

See 'man git' for possible values for GIT_TRACE.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: How to see command line arguments passed to program in core.sshcommand?
  2019-09-23  9:24 ` SZEDER Gábor
@ 2019-09-23 17:18   ` Jeffrey Walton
  2019-09-23 18:38     ` SZEDER Gábor
  0 siblings, 1 reply; 5+ messages in thread
From: Jeffrey Walton @ 2019-09-23 17:18 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Git List

On Mon, Sep 23, 2019 at 5:24 AM SZEDER Gábor <szeder.dev@gmail.com> 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@example.com: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@example.com '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@example.com: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@example.com '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@example.com: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@example.com '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@example.com'
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: How to see command line arguments passed to program in core.sshcommand?
  2019-09-23 17:18   ` Jeffrey Walton
@ 2019-09-23 18:38     ` SZEDER Gábor
  0 siblings, 0 replies; 5+ messages in thread
From: SZEDER Gábor @ 2019-09-23 18:38 UTC (permalink / raw)
  To: Jeffrey Walton; +Cc: Git List

On Mon, Sep 23, 2019 at 01:18:39PM -0400, Jeffrey Walton wrote:
> (A) core.sshCommand:
> 
>     sshcommand = "C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe"
> 
> Result:
> 
> $ GIT_TRACE=1 git clone ssh://jeffrey.walton@example.com: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@example.com '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@example.com: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@example.com '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@example.com: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@example.com '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@example.com'
> 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

Git's configuration file format allows optional double quotes around
the values of configuration variables.  Consequently all double quotes
in your examples above are treated as part of the file format and are
removed; you have to escape them if you want to keep them:

  [foo]
        one = "inside double quotes"
        two = \"need those double quotes\"
        three = "\"need these double quotes, too\""

  $ git config --get foo.one
  inside double quotes
  $ git config --get foo.two
  "need those double quotes"
  $ git config --get foo.three
  "need these double quotes, too"


> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: How to see command line arguments passed to program in core.sshcommand?
  2019-09-23  3:17 How to see command line arguments passed to program in core.sshcommand? Jeffrey Walton
  2019-09-23  9:24 ` SZEDER Gábor
@ 2019-09-24 17:12 ` Derrick Stolee
  1 sibling, 0 replies; 5+ messages in thread
From: Derrick Stolee @ 2019-09-24 17:12 UTC (permalink / raw)
  To: noloader, Git List

On 9/22/2019 11:17 PM, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I'm working in an unusual setup on WIndows. I need to 'git clone' over
> SSH, but a third party program has to handle the tunnel. It happens by
> using this git configuration:
> 
>     git config --global core.sshcommand "tunnel.exe ... <path-to-public-key>"
> 
> After I execute the 'git config' command, I open ~/.gitconfig and
> ensure the path is correct and quoted per Windows standards.
> 
> So far the result has been a failed authentication, which seems to
> indicate something went sideways using the public key. I don't receive
> an error from Git or or the tunnel program relating to a "file not
> found" (or any errors for that matter until authentication fails).
> 
> 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?

Have you tried GIT_TRACE=1 or GIT_TRACE2=1? Both options should record
a log entry for any spawned processes.

(You can also point these to fully-qualified filenames.)

Thanks,
-Stolee

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-09-24 17:12 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-23  3:17 How to see command line arguments passed to program in core.sshcommand? Jeffrey Walton
2019-09-23  9:24 ` SZEDER Gábor
2019-09-23 17:18   ` Jeffrey Walton
2019-09-23 18:38     ` SZEDER Gábor
2019-09-24 17:12 ` Derrick Stolee

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).