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

Win7 x64: x86 Java runtime creates bad PATH on x64 OS causing ' \Java\jre6\bin"" was unexpected at this time.' error

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: remoting
    • Labels:
      None
    • Environment:
      Win7 x64
    • Similar Issues:

      Description

      Win7 x64: x86 Java runtime creates bad PATH on x64 OS causing ' \Java\jre6\bin"" was unexpected at this time.' error

      I had installed the x86 Java 6, Version 6 update 29, (build 1.6.0_29-b11), which installs into C:\Program Files (x86)\Java\jre6. When I started the jenkins client and ran a build I received ' \Java\jre6\bin"" was unexpected at this time.' errors in the console any time a shell command was invoked on the slave.

      Upon investigation it appears that the Java runtime set to path to (as reported by the Manage Jenkins --> Manage Nodes --> My Slave --> Systeminfo page:

      C:\Program Files (x86)\Java\jre6\bin;...;"C:\Program Files (x86)\Java\jre6\bin"

      Searching about on the internet I see several projects reporting issues about unescaped parens being added to the path.
      https://issues.apache.org/jira/browse/GERONIMO-5365
      https://forums.oracle.com/forums/thread.jspa?threadID=2171702

      I can work around this issue by using the x64 JRE on 64-bit OS.

        Attachments

          Issue Links

            Activity

            Hide
            ffromm Frederik Fromm added a comment -

            moved to master-slave component

            Show
            ffromm Frederik Fromm added a comment - moved to master-slave component
            Hide
            scole66 Steven Cole added a comment - - edited

            This just happened to us; quite annoying. Our workaround is to assign the path at the top of any build scripts, as the "unexpected at this time" error was generated by the vcvarsall batch file (from Microsoft Visual Studio), and we have time to get in before that's actually called.

            But those quotation marks should never get there.

            Show
            scole66 Steven Cole added a comment - - edited This just happened to us; quite annoying. Our workaround is to assign the path at the top of any build scripts, as the "unexpected at this time" error was generated by the vcvarsall batch file (from Microsoft Visual Studio), and we have time to get in before that's actually called. But those quotation marks should never get there.
            Hide
            davidriggleman David Riggleman added a comment - - edited

            I found this issue quite frustrating. After wasting time wondering why my Powershell script worked if I ran it manually but not if it ran through Jenkins, I eventually came across this issue and determined the root cause. Yes, the issue may be listed as minor, but the considering headaches that it causes, it would seem to be worth the presumably minimal effort to fix this. My workaround was similar to what others have mentioned in manually fixing the path at the top of my script. Since I'm working with a Powershell script, here's the code I've got at the very top of my script to fix the problem:

            Perforce Script
            $env:PATH = $env:PATH -replace '"', ""
            
            Show
            davidriggleman David Riggleman added a comment - - edited I found this issue quite frustrating. After wasting time wondering why my Powershell script worked if I ran it manually but not if it ran through Jenkins, I eventually came across this issue and determined the root cause. Yes, the issue may be listed as minor, but the considering headaches that it causes, it would seem to be worth the presumably minimal effort to fix this. My workaround was similar to what others have mentioned in manually fixing the path at the top of my script. Since I'm working with a Powershell script, here's the code I've got at the very top of my script to fix the problem: Perforce Script $env:PATH = $env:PATH -replace ' "' , " "
            Hide
            kainjow Kevin Wojniak added a comment -

            Got this with Jenkins 1.522. Read somewhere else that the 64-bit version of Java works, not sure why though. So I uninstalled 32-bit Java and installed 64-bit version, and now the build script gets beyond this error.

            Show
            kainjow Kevin Wojniak added a comment - Got this with Jenkins 1.522. Read somewhere else that the 64-bit version of Java works, not sure why though. So I uninstalled 32-bit Java and installed 64-bit version, and now the build script gets beyond this error.
            Hide
            scole66 Steven Cole added a comment -

            @Kevin: The "reason" why the 32-bit version doesn't work is because that forces the path name to have "(x86)" embedded within. And the thing that makes the runtime path adds quotation marks when parentheses appear in the path. So when you install the 64-bit version of Java, the path doesn't have parentheses, and quotation marks are not added.

            Show
            scole66 Steven Cole added a comment - @Kevin: The "reason" why the 32-bit version doesn't work is because that forces the path name to have "(x86)" embedded within. And the thing that makes the runtime path adds quotation marks when parentheses appear in the path. So when you install the 64-bit version of Java, the path doesn't have parentheses, and quotation marks are not added.
            Hide
            colina188 Colin Andrews added a comment -

            I am still seeing quoted path to the jre bin added to path even when I changed to the 64 bit JRE.

            I can't believe this still hasn't been fixed. This makes a large category of jobs un-runnable under Jenkins on Windows.

            Show
            colina188 Colin Andrews added a comment - I am still seeing quoted path to the jre bin added to path even when I changed to the 64 bit JRE. I can't believe this still hasn't been fixed. This makes a large category of jobs un-runnable under Jenkins on Windows.
            Hide
            pablaasmo Per Arnold Blaasmo added a comment -

            The problem I see is that Jenkins seems to add the path to java with quotes around.

            So then I get a path that looks like

            C:\somepath\withsub;C:\another path with spaces\withsub;"C:\Program Files (x86)\Java\jre7\bin"
            

            So when a bat file (in my case) or another program tries to manipulate the path by adding something it quotes the whole path so you get:

            "C:\somepath\withsub;C:\another path with spaces\withsub;"C:\Program Files (x86)\Java\jre7\bin";C:\addedpath\"
            

            Thereby actually un-quoteing the part of the path that set the java path.
            So therefor you get an error.

            So the questions is:

            1. Where does Jenkins add the java path?
            2. What is the correct way to add a path element?
            3. is it Jenkins or the other programs that are doing the error?
            Show
            pablaasmo Per Arnold Blaasmo added a comment - The problem I see is that Jenkins seems to add the path to java with quotes around. So then I get a path that looks like C:\somepath\withsub;C:\another path with spaces\withsub; "C:\Program Files (x86)\Java\jre7\bin" So when a bat file (in my case) or another program tries to manipulate the path by adding something it quotes the whole path so you get: "C:\somepath\withsub;C:\another path with spaces\withsub;" C:\Program Files (x86)\Java\jre7\bin ";C:\addedpath\" Thereby actually un-quoteing the part of the path that set the java path. So therefor you get an error. So the questions is: Where does Jenkins add the java path? What is the correct way to add a path element? is it Jenkins or the other programs that are doing the error?
            Hide
            robertg2 Robert Grampp added a comment - - edited

            I would like to see this bug raised to level MAJOR since a command line build with Microsoft Visual Studio 11 is impossible with this Jenkins behaviour. It crashes when calling Microsofts script vcvarsall.bat!
            Job log:

            C:\Users\plossys\workspace\Test_Slave_Windows_VC_Build>path
            PATH=C:\Program Files (x86)\Java\jdk1.6.0_37_32b/bin;C:\Program Files (x86)\Java\jdk1.6.0_37_32b/bin;C:\Program Files (x86)\Java\jre6\bin;C:\Program Files (x86)\Mozilla Firefox;C:\Program Files (x86)\Java\jre6\bin;C:\ruby200\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseGit\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\VisualSVN\bin;C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\Chocolatey\bin;C:\sysinternals;"C:\Program Files (x86)\Java\jre6\bin"
            
            C:\Users\plossys\workspace\Test_Slave_Windows_VC_Build>"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" amd64 
            \Java\jre6\bin"" was unexpected at this time.
            Build step 'Windows Batch-Datei ausführen' marked build as failure
            

            Jenkins slave is connected via JNLP launcher (Java Applet), not via Windows service cause that raised too much hassle with firewall/group policy issues.

            Show
            robertg2 Robert Grampp added a comment - - edited I would like to see this bug raised to level MAJOR since a command line build with Microsoft Visual Studio 11 is impossible with this Jenkins behaviour. It crashes when calling Microsofts script vcvarsall.bat! Job log: C:\Users\plossys\workspace\Test_Slave_Windows_VC_Build>path PATH=C:\Program Files (x86)\Java\jdk1.6.0_37_32b/bin;C:\Program Files (x86)\Java\jdk1.6.0_37_32b/bin;C:\Program Files (x86)\Java\jre6\bin;C:\Program Files (x86)\Mozilla Firefox;C:\Program Files (x86)\Java\jre6\bin;C:\ruby200\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseGit\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\VisualSVN\bin;C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\Chocolatey\bin;C:\sysinternals; "C:\Program Files (x86)\Java\jre6\bin" C:\Users\plossys\workspace\Test_Slave_Windows_VC_Build> "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" amd64 \Java\jre6\bin"" was unexpected at this time. Build step 'Windows Batch-Datei ausführen' marked build as failure Jenkins slave is connected via JNLP launcher (Java Applet), not via Windows service cause that raised too much hassle with firewall/group policy issues.
            Hide
            hallen19 Harshi Allen added a comment -

            I agree! This should be changed to Major. We're having the same issue with VS 2012 scripts. We are getting around the issue by setting the PATH variable not to have those extra quotation marks right before calling the VS scripts.

            Show
            hallen19 Harshi Allen added a comment - I agree! This should be changed to Major. We're having the same issue with VS 2012 scripts. We are getting around the issue by setting the PATH variable not to have those extra quotation marks right before calling the VS scripts.
            Hide
            robertg2 Robert Grampp added a comment -

            Changed level to Major since slave build with MS Visual Studio is impossible with this Jenkins behaviour.

            Show
            robertg2 Robert Grampp added a comment - Changed level to Major since slave build with MS Visual Studio is impossible with this Jenkins behaviour.
            Hide
            canilao Chris Anilao added a comment -

            I had a similar issue related to microsoft's webdeploy (http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx). I worked around the issue by using the shortened versions of the directories. You can find out what what they are by typing dir /x.

            My command ended up looking like this:

            MSBuild c:\PROGRA~2\Jenkins\jobs\REPVIE~1\workspace\Builder\RepView\RepView.csproj /p:DeployOnBuild=true /p:PublishProfile=JenkinsDeployment
            c:\PROGRA~2\Jenkins\jobs\REPVIE~1\workspace\Builder\RepView\obj\Debug\Package\RepView.deploy.cmd /y /M:http://<target-address> /u:<username> /p:<password>

            Because the deploy.cmd file is generated, using the shortened names for the directories when MSBuild is called, gets around this issue. I hope this applies to other issues that people are having with this bug.

            Show
            canilao Chris Anilao added a comment - I had a similar issue related to microsoft's webdeploy ( http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx ). I worked around the issue by using the shortened versions of the directories. You can find out what what they are by typing dir /x. My command ended up looking like this: MSBuild c:\PROGRA~2\Jenkins\jobs\REPVIE~1\workspace\Builder\RepView\RepView.csproj /p:DeployOnBuild=true /p:PublishProfile=JenkinsDeployment c:\PROGRA~2\Jenkins\jobs\REPVIE~1\workspace\Builder\RepView\obj\Debug\Package\RepView.deploy.cmd /y /M:http://<target-address> /u:<username> /p:<password> Because the deploy.cmd file is generated, using the shortened names for the directories when MSBuild is called, gets around this issue. I hope this applies to other issues that people are having with this bug.
            Hide
            robertg2 Robert Grampp added a comment -

            Hi Chris,
            thanks for your suggestion, but the problem isn't having spaces in a directory path.
            The initial problem is that Jenkins adds the path to Java surrounded with quotes!
            Jenkins adds

            ;"C:\Program Files (x86)\Java\jre6\bin"

            to PATH variable.

            On Windows even directories containing spaces are added without surrounded spaces.
            That's the change that the Jenkins developers should do.

            You see this when calling path command on any Windows system, e. g. =>

            PATH=C:\Program Files\Common Files\Microsoft Shared\...
            Show
            robertg2 Robert Grampp added a comment - Hi Chris, thanks for your suggestion, but the problem isn't having spaces in a directory path. The initial problem is that Jenkins adds the path to Java surrounded with quotes! Jenkins adds ; "C:\Program Files (x86)\Java\jre6\bin" to PATH variable. On Windows even directories containing spaces are added without surrounded spaces. That's the change that the Jenkins developers should do. You see this when calling path command on any Windows system, e. g. => PATH=C:\Program Files\Common Files\Microsoft Shared\...
            Hide
            biriuck ilie daniel added a comment -

            Workaround for my ant script:
            <target name="runBat">

            <!-- Remove quotes from Path: https://issues.jenkins-ci.org/browse/JENKINS-11992 -->
            <loadresource property="clean.Path">
            <propertyresource name="env.Path" />
            <filterchain>
            <tokenfilter>
            <filetokenizer />
            <replacestring from=""" to="" />
            </tokenfilter>
            </filterchain>
            </loadresource>

            <exec executable="cmd.exe" spawn="yes" vmlauncher="false" dir="./${run.dir}">
            <env key="BUILD_ID" value="dontKillMe" />
            <env key="Path" value="${clean.Path}" />
            <arg line="/k call ${bat.file}" />
            </exec>
            </target>

            Show
            biriuck ilie daniel added a comment - Workaround for my ant script: <target name="runBat"> <!-- Remove quotes from Path: https://issues.jenkins-ci.org/browse/JENKINS-11992 --> <loadresource property="clean.Path"> <propertyresource name="env.Path" /> <filterchain> <tokenfilter> <filetokenizer /> <replacestring from=""" to="" /> </tokenfilter> </filterchain> </loadresource> <exec executable="cmd.exe" spawn="yes" vmlauncher="false" dir="./${run.dir}"> <env key="BUILD_ID" value="dontKillMe" /> <env key="Path" value="${clean.Path}" /> <arg line="/k call ${bat.file}" /> </exec> </target>
            Hide
            ggeorgea Gwen Georgeault added a comment -

            I patch the problem doing this, essentially removing the quotes in the PATH variable prior to calling the batch file exposing the problem:

            set path=%path:"=%
            CALL "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86

            Show
            ggeorgea Gwen Georgeault added a comment - I patch the problem doing this, essentially removing the quotes in the PATH variable prior to calling the batch file exposing the problem: set path=%path:"=% CALL "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86
            Hide
            robertg2 Robert Grampp added a comment -

            I wished, one of the Jenkins developers would do that in the Jenkins code ...

            Show
            robertg2 Robert Grampp added a comment - I wished, one of the Jenkins developers would do that in the Jenkins code ...
            Hide
            astraujums Atis Straujums added a comment - - edited

            Our solution (workaround) to this problem was to install Java in a location without spaces in the path.

            Show
            astraujums Atis Straujums added a comment - - edited Our solution (workaround) to this problem was to install Java in a location without spaces in the path.
            Hide
            abeben Adam Beben added a comment -

            For me workaround to this problem was to add JAVA_HOME environement variable pointing to jdk. eg: C:\Java\jdk1.8.0_66

            Show
            abeben Adam Beben added a comment - For me workaround to this problem was to add JAVA_HOME environement variable pointing to jdk. eg: C:\Java\jdk1.8.0_66
            Hide
            robertg2 Robert Grampp added a comment -

            The description is misleading. It's not the Java runtime that set the path the wrong way.
            It is Jenkins, that adds the PATH element illegally surrounded by quotes!
            Thus the Jenkins code has to be corrected.
            Neither on Windows nor (IMHO) on unixoid systems a PATH element is surrunded by quote signs.
            It's annoying to have either the PATH be corrected at beginning of the Jenkins job definition or moving the JRE to a path not containing blanks.

            Show
            robertg2 Robert Grampp added a comment - The description is misleading. It's not the Java runtime that set the path the wrong way. It is Jenkins, that adds the PATH element illegally surrounded by quotes! Thus the Jenkins code has to be corrected. Neither on Windows nor (IMHO) on unixoid systems a PATH element is surrunded by quote signs. It's annoying to have either the PATH be corrected at beginning of the Jenkins job definition or moving the JRE to a path not containing blanks.
            Hide
            sravya Sravya Pudota added a comment -

            Any updates or any temporary fixes?

            Show
            sravya Sravya Pudota added a comment - Any updates or any temporary fixes?
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Sorry, I do not have capacity to fix it.

            Anyway, running Jenkins on 64bit Windows with 32bit Java is not something stable. E.g. see https://github.com/kohsuke/winp#platform-support , you will be likely getting runaway processes when aborting builds

            Show
            oleg_nenashev Oleg Nenashev added a comment - Sorry, I do not have capacity to fix it. Anyway, running Jenkins on 64bit Windows with 32bit Java is not something stable. E.g. see https://github.com/kohsuke/winp#platform-support  , you will be likely getting runaway processes when aborting builds

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              mmacvicar Mark MacVicar
              Votes:
              23 Vote for this issue
              Watchers:
              28 Start watching this issue

                Dates

                Created:
                Updated: