Not possible to set GIT_SSH to a path with spaces

[klikh]

Windows 7 64-bit
git version 2.7.2.windows.1
Git Bash

I have an executable script located in a folder with spaces, and what to use it for git over SSH. However, it seems that it is simply not possible to define GIT_SSH so that it points to a path with spaces.

Neither of the following works:

$ export GIT_SSH=C:\\Users\\John\ Smith\\git-ssh-.bat
$ export GIT_SSH=/c/Users/John\ Smith/git-ssh-.bat

$ git fetch
'C:\Users\John' is not recognized as an internal or external command,
operable program or batch file.
fatal: Could not read from remote repository.

Quoting gives another error but still doesn't work:

$ export GIT_SSH="/c/Users/John\ Smith/git-ssh-.bat"
$ export GIT_SSH=\"/c/Users/John\ Smith/git-ssh-.bat\"
$ export GIT_SSH="C:\\Users\\John\ Smith\\git-ssh-.bat"
$ export GIT_SSH="C:\Users\John Smith\git-ssh-.bat"

$ git fetch
error: cannot spawn C:/Users/John/ Smith/git-ssh-.bat: No such file or directory
fatal: unable to fork

I would appreciate if you give me a workaround (if there is any workaround except "use path without spaces") until the issue is fixed.

[klikh]

Googling shows that the issue exists for a long time, and was already reported but was not ported to this bugtracker.

[dscho]

@klikh the quoted approach is the correct one, but I suspect that we never supported calling .bat scripts, only .sh ones.

[klikh]

the quoted approach is the correct one

Which one exactly?

I suspect that we never supported calling .bat scripts, only .sh ones.

.bat scripts are perfectly supported (at least they work - intentionally or not :) ) unless the path to the script contains a space.

However, I'll check sh as well, thanks.

[dscho]

the quoted approach is the correct one

Which one exactly?

Sorry. I meant this one:

$ export GIT_SSH="C:\\Users\\John\ Smith\\git-ssh-.bat"

However, you are correct:

.bat scripts are perfectly supported

Whoa, you're right! I did not know...

And I did verify that it works without spaces in the path and does not work with spaces. The easiest workaround for you is to use the short names (for backwards-compatibility, every file name has an alternate 8.3 compliant name, in your case it might be C:\Users\JOHNSM~1\GIT-SS~1.BAT).

It appears that something spooky is going on in the CreateProcessW() call: it simply does not work for .bat files if the the lpApplicationName parameter contains spaces, and even if it is replaced by the short path (using the GetShortPathName() function), if the lpCommandLine does not match the short path, it still will fail.

It does work, however, if quoting the first argument in lpCommandLine and passing NULL as lpApplicationName.

[dscho]

Fixed via 8086988

[klikh]

Wow. Thanks for the quick fix!

The easiest workaround for you is to use the short names (for backwards-compatibility, every file name has an alternate 8.3 compliant nam

Yep, the workaround is clear, but the problem is how to identify this short name. E.g. in my Java program there is no straightforward method to do it, only by making a native system call.

[avih]

every file name has an alternate 8.3 compliant name

AFAIK, on windows 8 and later, 8.3 names are only enabled by default on drive C (try dir /X)

[dscho]

on windows 8 and later, 8.3 names are only enabled by default on drive C

Would you have a reference for this?

[avih]

Would you have a reference for this?

Nothing too concrete, but that's my recollection from some time ago when I checked the subject, and when I search now I also see people who don't have 8.3 names and how to enable them (fsutil apparently).

Also, on few win7 systems which I checked just now they have short names on non C drives, and on win8/10 which I checked there are no 8.3 names on non-C drives.

So so far, I can't find evidence to contradict this.

[dscho]

So so far, I can't find evidence to contradict this.

Hmm. I hoped for some link to an official statement that positively verifies this, not for the absence of contradicting evidence.

[avih]

Same, but I couldn't find one.