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

          Todd Boyd added a comment -

          We are using username/password. There is a space in our workspace folder names, so I'm 99% sure that's what is going on. They start with "C:\Program Files (x86)".

          Todd Boyd added a comment - We are using username/password. There is a space in our workspace folder names, so I'm 99% sure that's what is going on. They start with "C:\Program Files (x86)".

          Ryan Hinton added a comment - - edited

          Just starting receiving this error after upgrading and we have concluded it to be the same issue as Todd Boyd has explained above.  We currently cannot build using Jenkins at this time.  Is there an ETA when this will be fixed by chance?

          Thank you.

          Ryan Hinton added a comment - - edited Just starting receiving this error after upgrading and we have concluded it to be the same issue as Todd Boyd has explained above.  We currently cannot build using Jenkins at this time.  Is there an ETA when this will be fixed by chance? Thank you.

          Mark Waite added a comment - - edited

          hinton I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. Flavio's case involved ssh based access to the repository, and private keys. tmboyd1's case used http/https based access to the repository with a username and password.

          I suspect you'll need to fall back to the previous version of the git client plugin for the short term. Refer to JENKINS-43931 for more details on the problem you're seeing.

          My most recent comment on JENKINS-43931 includes a link to a snapshot build of the git client plugin that you could also try if you'd rather not fall back to the previous version of the git client plugin.

          Mark Waite added a comment - - edited hinton I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. Flavio's case involved ssh based access to the repository, and private keys. tmboyd1 's case used http/https based access to the repository with a username and password. I suspect you'll need to fall back to the previous version of the git client plugin for the short term. Refer to JENKINS-43931 for more details on the problem you're seeing. My most recent comment on JENKINS-43931 includes a link to a snapshot build of the git client plugin that you could also try if you'd rather not fall back to the previous version of the git client plugin.

          Ryan Hinton added a comment - - edited

          I downgraded the Git plugin and I am still receiving the problem.  There were a plethora of plugin upgrades that occurred at the same time.  Is it possible this could be caused by a different plugin?

          UPDATE: I just noticed your prompt reply, Mark. Thank you.  You mentioned Git Client plugin.  I downgraded the Git plugin.  I will downgrade Git Client plugin now.

          2nd UPDATE: I'm just confirming that after downgrading the Git Client plugin, my builds are operational, again.  I will look into the snapshots seeing that I am back to receiving a warning at the top of the Jenkins app.  Thank you for your assistance, Mark.

          Ryan Hinton added a comment - - edited I downgraded the Git plugin and I am still receiving the problem.  There were a plethora of plugin upgrades that occurred at the same time.  Is it possible this could be caused by a different plugin? UPDATE: I just noticed your prompt reply, Mark. Thank you.  You mentioned Git Client plugin.  I downgraded the Git plugin.  I will downgrade Git Client plugin now. 2nd UPDATE: I'm just confirming that after downgrading the Git Client plugin, my builds are operational, again.  I will look into the snapshots seeing that I am back to receiving a warning at the top of the Jenkins app.  Thank you for your assistance, Mark.

          Ed Sarrazin added a comment -

          I was fighting through this same issue today.  

          Failed to connect to repository : Command "git.exe ls-remote -h http://scm.abc.net:7990/scm/~blahapp-ui.git HEAD" returned status code -1:
          stdout: 
          stderr: 'D:\Apps\Tomcat\Tomcat' is not recognized as an internal or external command, 
          operable program or batch file.

          I thought it was a pathing issue to git as well, but I was seeing a partial path on the D:\Apps\Tomcat\Tomcat part of the error as well.  Turns out the installation for Tomcat 9 has spaces in it (D:\Apps\Tomcat\Tomcat 9.0).  What could be causing this when using the Git plugin?  Well their documentation says it needs write access to the temp directory, which defaulted to Tomcat 9.0\temp.  I went into the startup parameters of Tomcat and set the temp directory ( -Djava.io.tmpdir=d:\temp) and that fixed the error.  Looks like it is the spacing in the default install path.

          Git doc reference: https://wiki.jenkins.io/display/JENKINS/Git+Client+Plugin - under Gotchas

          Ed

          Ed Sarrazin added a comment - I was fighting through this same issue today.   Failed to connect to repository : Command "git.exe ls-remote -h  http://scm.abc.net:7990/scm/~blahapp-ui.git  HEAD" returned status code -1: stdout:  stderr: ' D:\Apps\Tomcat\Tomcat ' is not recognized as an internal or external command,  operable program or batch file. I thought it was a pathing issue to git as well, but I was seeing a partial path on the D:\Apps\Tomcat\Tomcat part of the error as well.  Turns out the installation for Tomcat 9 has spaces in it (D:\Apps\Tomcat\Tomcat 9.0).  What could be causing this when using the Git plugin?  Well their documentation says it needs write access to the temp directory, which defaulted to Tomcat 9.0\temp.  I went into the startup parameters of Tomcat and set the temp directory ( -Djava.io.tmpdir=d:\temp) and that fixed the error.  Looks like it is the spacing in the default install path. Git doc reference: https://wiki.jenkins.io/display/JENKINS/Git+Client+Plugin  - under  Gotchas Ed

          Mark Waite added a comment -

          chewy, I thought that a warning was printed by the plugin if it detected a space in the Windows temporary directory path.  Could you check the console output of one of your failing jobs to see if there is a warning about temporary directory names which contain ' '.

          You may also want to try git client plugin 2.4.6 which includes a fix for several workspace path related regressions that were introduced with the security fixes in git client plugin 2.4.4.

          Mark Waite added a comment - chewy , I thought that a warning was printed by the plugin if it detected a space in the Windows temporary directory path.  Could you check the console output of one of your failing jobs to see if there is a warning about temporary directory names which contain ' '. You may also want to try git client plugin 2.4.6 which includes a fix for several workspace path related regressions that were introduced with the security fixes in git client plugin 2.4.4.

          Ed Sarrazin added a comment -

          markewaite, We are on 2.4.6 and the problem is now resolved after setting the temp dir.  This was not in any console log of a job that I saw.  The polling log just ended with the "git.exe ls-remote -h........ # timeout 10" and no errors.  When polling the job, it just would never detect changes (we had a post commit hook added to solve, but that was a pain if 20 commits happened at once).  The only time we saw this error was configuring a job and you had to wait like 10 minutes for the error to show up in the designer.

          Ed Sarrazin added a comment - markewaite , We are on 2.4.6 and the problem is now resolved after setting the temp dir.  This was not in any console log of a job that I saw.  The polling log just ended with the "git.exe ls-remote -h........ # timeout 10" and no errors.  When polling the job, it just would never detect changes (we had a post commit hook added to solve, but that was a pain if 20 commits happened at once).  The only time we saw this error was configuring a job and you had to wait like 10 minutes for the error to show up in the designer.

          Mark Waite added a comment -

          chewy that says that the warning is not being made visible enough.  I'll need to investigate why that warning wasn't visible to you.

          The same problem hit me (and should have been detected by a warning), so it is worth some investigation.

          Mark Waite added a comment - chewy that says that the warning is not being made visible enough.  I'll need to investigate why that warning wasn't visible to you. The same problem hit me (and should have been detected by a warning), so it is worth some investigation.

          Ed Sarrazin added a comment -

          markewaite - Sure looks a lot like Flavios problem to me.  Hopefully this helps him too.

          Ed Sarrazin added a comment - markewaite - Sure looks a lot like Flavios problem to me.  Hopefully this helps him too.

          Sang B. Han added a comment -

          When ssh account with private certification fails to log in because id or password is wrong, it generate "stderr: 'C:\Program' is not recognized as an internal or external command, '" error message. Wrong error message is displayed.

           

          It's funny that the wrong credential is works in other place like Jenkinsfile. It fails only in scan pipeline. Because of that, it takes wrong time that i find the reason.

           

           

           

          Sang B. Han added a comment - When ssh account with private certification fails to log in because id or password is wrong, it generate "stderr: 'C:\Program' is not recognized as an internal or external command, '" error message. Wrong error message is displayed.   It's funny that the wrong credential is works in other place like Jenkinsfile. It fails only in scan pipeline. Because of that, it takes wrong time that i find the reason.      

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

              Created:
              Updated: