moved to master-slave component

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.

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:

$env:PATH = $env:PATH -replace '"', ""

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.

@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.

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.

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?

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.

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

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:

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.

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\...

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>

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

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

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

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

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.

Any updates or any temporary fixes?

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