Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-30927

'C:\Program' is not recognized as an internal or external command

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • git-client-plugin
    • None

      I tried to setup a test project, using a git project connecting through ssh.
      After selecting the ssh credential and adding the git URL (ssh://git@bitbucket.org/CLIENT/test.git) I get the following message:
      ---------------
      Failed to connect to repository : Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true ls-remote -h ssh://git@bitbucket.org/CLIENT/test.git HEAD" returned status code 128:
      stdout:
      stderr: 'C:\Program' is not recognized as an internal or external command,
      operable program or batch file.
      fatal: Could not read from remote repository.

      Please make sure you have the correct access rights
      and the repository exists.
      --------------

      My setup:
      Jenkins: 1.633
      GIT client plugin: 1.19.0
      GIT plugin: 2.4.0

      Jenkins Git Configuration is set to: C:/Progra~1/Git/bin/git.exe
      Git 2.6.1 from https://git-scm.com/downloads.

          [JENKINS-30927] 'C:\Program' is not recognized as an internal or external command

          Flavio Donzé created issue -
          Mark Waite made changes -
          Component/s Original: git-plugin [ 15543 ]
          Mark Waite made changes -
          Assignee Original: Nicolas De Loof [ ndeloof ]

          Mark Waite added a comment -

          Are you certain that the git program is really in C:\Progra~1\Git\bin\git.exe, or is it in C:\Progra~2\Git\bin\git.exe (or some other differently named location)? For example, if you run a command prompt build step in a job which has no scm, can that command prompt build step execute the command "C:\Progra~1\Git\bin\git.exe"? Can it execute the command C:/Progra~1/Git/bin/git.exe?

          Have you tried specifying the location of the git executable with the spaces in the path to git, as in "C:\Program Files\Git\bin\git.exe"? That is the technique I use on most of my test and production machines and it works quite well.

          Is there a reason you feel you need to use the mangled form of the path rather than the form which includes spaces?

          Mark Waite added a comment - Are you certain that the git program is really in C:\Progra~1\Git\bin\git.exe, or is it in C:\Progra~2\Git\bin\git.exe (or some other differently named location)? For example, if you run a command prompt build step in a job which has no scm, can that command prompt build step execute the command "C:\Progra~1\Git\bin\git.exe"? Can it execute the command C:/Progra~1/Git/bin/git.exe? Have you tried specifying the location of the git executable with the spaces in the path to git, as in "C:\Program Files\Git\bin\git.exe"? That is the technique I use on most of my test and production machines and it works quite well. Is there a reason you feel you need to use the mangled form of the path rather than the form which includes spaces?

          Flavio Donzé added a comment -

          Yes I'm sure the path is correct, I also tried:
          C:\Program Files\Git\bin\git.exe
          C:/Program Files/Git/bin/git.exe

          I switched to the mangled form because of the error message:
          stderr: 'C:\Program' is not recognized as an internal or external command,
          The message indicates that something is wrong with the path.

          Yes other paths work, e.g. https://.

          Flavio Donzé added a comment - Yes I'm sure the path is correct, I also tried: C:\Program Files\Git\bin\git.exe C:/Program Files/Git/bin/git.exe I switched to the mangled form because of the error message: stderr: 'C:\Program' is not recognized as an internal or external command, The message indicates that something is wrong with the path. Yes other paths work, e.g. https:// .

          Mark Waite added a comment - - edited

          If other git URLs work (like https://github.com/jenkinsci/git-client-plugin or git://github.com/jenkinsci/git-client-plugin.git/) then the likely problem is not in the git program itself, but in the attempt by the git plugin to run the ssh.exe program (or some other program) separately for authentication.

          There is a report in JENKINS-30045 which reports that two users were having problems with the git 2.5.0 version not being able to find the ssh.exe program.

          Is there anything else distinctive or unique about your git configuration?

          Mark Waite added a comment - - edited If other git URLs work (like https://github.com/jenkinsci/git-client-plugin or git://github.com/jenkinsci/git-client-plugin.git/) then the likely problem is not in the git program itself, but in the attempt by the git plugin to run the ssh.exe program (or some other program) separately for authentication. There is a report in JENKINS-30045 which reports that two users were having problems with the git 2.5.0 version not being able to find the ssh.exe program. Is there anything else distinctive or unique about your git configuration?

          Flavio Donzé added a comment -

          Yes both https://github.com/jenkinsci/git-client-plugin and git://github.com/jenkinsci/git-client-plugin.git/ are working.

          Here some system variables, PATH I reduced to the relevant entries. I use the mangled form for most jenkins relevant entries, since I had path problems in the past.
          GIT_HOME = C:\Progra~1\Git\bin
          GIT_SSH = C:\Progra~1\Git\usr\bin\ssh.exe
          JAVA_HOME = C:\Progra~1\Java\jdk1.8.0_60
          PATH = C:\Progra~1\Java\jdk1.8.0_60\bin;C:\Progra~1\Java\jdk1.8.0_60\jre\bin\client;C:\Progra~1\TortoiseGit\bin;C:\Program Files\TortoiseGit\bin;C:\Progra~1\Git\bin;C:\Progra~1\Git\usr\bin

          The private ssh key is stored in: %USERPROFILE%\.ssh\id_rsa
          The public ssh key %USERPROFILE%\.ssh\id_rsa.pub is added in bitbucket.
          If I run "ssh -T git@bitbucket.org" in a cmd, I get the following output after entering the passphrase:
          logged in as USERNAME
          You can use git or hg to connect to Bitbucket. Shell access is disabled.

          I copied the value of the private key into jekins credential-store and added the passphrase.

          Flavio Donzé added a comment - Yes both https://github.com/jenkinsci/git-client-plugin and git://github.com/jenkinsci/git-client-plugin.git/ are working. Here some system variables, PATH I reduced to the relevant entries. I use the mangled form for most jenkins relevant entries, since I had path problems in the past. GIT_HOME = C:\Progra~1\Git\bin GIT_SSH = C:\Progra~1\Git\usr\bin\ssh.exe JAVA_HOME = C:\Progra~1\Java\jdk1.8.0_60 PATH = C:\Progra~1\Java\jdk1.8.0_60\bin;C:\Progra~1\Java\jdk1.8.0_60\jre\bin\client;C:\Progra~1\TortoiseGit\bin;C:\Program Files\TortoiseGit\bin;C:\Progra~1\Git\bin;C:\Progra~1\Git\usr\bin The private ssh key is stored in: %USERPROFILE%\.ssh\id_rsa The public ssh key %USERPROFILE%\.ssh\id_rsa.pub is added in bitbucket. If I run "ssh -T git@bitbucket.org" in a cmd, I get the following output after entering the passphrase: logged in as USERNAME You can use git or hg to connect to Bitbucket. Shell access is disabled. I copied the value of the private key into jekins credential-store and added the passphrase.

          Flavio Donzé added a comment -

          Additional information, I now tried to create a ssh key without passphrase (just for testing), getting the same error.

          Flavio Donzé added a comment - Additional information, I now tried to create a ssh key without passphrase (just for testing), getting the same error.

          Mark Waite added a comment -

          Thanks for the additional information. It hints at several different areas which might be problems. Unfortunately, none of them seem likely (to me) to actually address the error message that is being reported.

          JENKINS-20879 reports that passphrase protected ssh keys don't work on Windows. There is a comment in that bug report which hints they might have worked at one time, but I spent several hours trying to find a way to make them work on Windows without success. My suspicion is that they never worked on Windows. There are even cases still today where they do not work on Linux.

          JENKINS-30755 reports that the GIT_HOME variable is not used in the git source code or in the git client plugin source code or in the git plugin source code. I don't think it will harm your installation, but as far as I can tell, it is unnecessary.

          JENKINS-20356 reports that a windows slave (or master) running as a service can't clone using an ssh private key. If Jenkins is running as a Windows service, I have little hope for you to be able to use ssh protected credentials.

          JENKINS-24368 and JENKINS-26757 report two different authentication problems that seem to be specific to bitbucket repositories.

          JENKINS-30045 reports a case where two users have a git 2.5.0 (and 2.6.0) installation on Windows that can't find ssh.exe. I haven't found (yet) what is different about their installation compared to the many installations I'm using of git 2.5.0 and git 2.6.0 for Windows, but they clearly have seen a problem.

          Have you attempted removing the Tortoise Git entries from your PATH, in case programs in those directories are returning different results than programs in the git distribution?

          Have you attempted to remove the GIT_SSH environment variable and instead allow the plugin to manage the value of GIT_SSH? There is code in the plugin that attempts several ways of guessing the correct value to assign to GIT_SSH.

          Are you using a Jenkins credential to define the credentials, or only relying on the private key stored in %USERPROFILE%\.ssh\id_rsa? The plugin has worked well for me using the Jenkins credentials system. I don't test with credentials stored locally in %USERPROFILE%\.ssh\id_rsa.

          Mark Waite added a comment - Thanks for the additional information. It hints at several different areas which might be problems. Unfortunately, none of them seem likely (to me) to actually address the error message that is being reported. JENKINS-20879 reports that passphrase protected ssh keys don't work on Windows . There is a comment in that bug report which hints they might have worked at one time, but I spent several hours trying to find a way to make them work on Windows without success. My suspicion is that they never worked on Windows. There are even cases still today where they do not work on Linux. JENKINS-30755 reports that the GIT_HOME variable is not used in the git source code or in the git client plugin source code or in the git plugin source code. I don't think it will harm your installation, but as far as I can tell, it is unnecessary. JENKINS-20356 reports that a windows slave (or master) running as a service can't clone using an ssh private key. If Jenkins is running as a Windows service, I have little hope for you to be able to use ssh protected credentials. JENKINS-24368 and JENKINS-26757 report two different authentication problems that seem to be specific to bitbucket repositories. JENKINS-30045 reports a case where two users have a git 2.5.0 (and 2.6.0) installation on Windows that can't find ssh.exe. I haven't found (yet) what is different about their installation compared to the many installations I'm using of git 2.5.0 and git 2.6.0 for Windows, but they clearly have seen a problem. Have you attempted removing the Tortoise Git entries from your PATH, in case programs in those directories are returning different results than programs in the git distribution? Have you attempted to remove the GIT_SSH environment variable and instead allow the plugin to manage the value of GIT_SSH? There is code in the plugin that attempts several ways of guessing the correct value to assign to GIT_SSH. Are you using a Jenkins credential to define the credentials, or only relying on the private key stored in %USERPROFILE%\.ssh\id_rsa? The plugin has worked well for me using the Jenkins credentials system. I don't test with credentials stored locally in %USERPROFILE%\.ssh\id_rsa.

          Flavio Donzé added a comment - - edited

          Thanks for your information and thoughts.

          I removed the GIT_SSH and the TortoiseGIT entries in the PATH variable. Same result, still getting the error.

          This is the log I get if I execute the build:

          Cloning repository ssh://git@bitbucket.org/CLIENT/test.git
          > C:/Progra~1/Git/bin/git.exe init DIRECTORY\test_ssh # timeout=10
          Fetching upstream changes from ssh://git@bitbucket.org/CLIENT/test.git
          > C:/Progra~1/Git/bin/git.exe --version # timeout=10
          using GIT_SSH to set credentials bitbucket nopass
          > C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/:refs/remotes/origin/
          ERROR: Error cloning remote repo 'origin'
          hudson.plugins.git.GitException: Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/:refs/remotes/origin/" returned status code 128:
          stdout:
          stderr: 'C:\Program' is not recognized as an internal or external command,
          operable program or batch file.
          fatal: Could not read from remote repository.

          Please make sure you have the correct access rights
          and the repository exists.

          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:505)
          at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1003)
          at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
          at hudson.scm.SCM.checkout(SCM.java:485)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
          at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
          at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
          at hudson.model.Run.execute(Run.java:1741)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:98)
          at hudson.model.Executor.run(Executor.java:408)
          ERROR: null
          Finished: FAILURE

          Interesting if I execute the commands, as printed in the log, in a normal CMD it works. I still don't know where the 'C:\Program' is coming from, since all my relevant paths are with ~.

          Flavio Donzé added a comment - - edited Thanks for your information and thoughts. I removed the GIT_SSH and the TortoiseGIT entries in the PATH variable. Same result, still getting the error. This is the log I get if I execute the build: Cloning repository ssh://git@bitbucket.org/CLIENT/test.git > C:/Progra~1/Git/bin/git.exe init DIRECTORY\test_ssh # timeout=10 Fetching upstream changes from ssh://git@bitbucket.org/CLIENT/test.git > C:/Progra~1/Git/bin/git.exe --version # timeout=10 using GIT_SSH to set credentials bitbucket nopass > C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/ :refs/remotes/origin/ ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/ :refs/remotes/origin/ " returned status code 128: stdout: stderr: 'C:\Program' is not recognized as an internal or external command, operable program or batch file. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:505) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1003) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408) ERROR: null Finished: FAILURE Interesting if I execute the commands, as printed in the log, in a normal CMD it works. I still don't know where the 'C:\Program' is coming from, since all my relevant paths are with ~.

            Unassigned Unassigned
            flaviodonze Flavio Donzé
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: