Bug 228730

http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jruntime

Changes to Runtime.exec

On Windows platform, the decoding of command strings specified to Runtime.exec(String), Runtime.exec(String,String[]) and Runtime.exec(String,String[],File) methods, has been improved to follow the specification more closely. This may cause problems for applications that are using one or more of these methods with commands that contain spaces in the program name, or are invoking these methods with commands that are not quoted correctly.

For example, Runtime.getRuntime().exec("C:\\My Programs\\foo.exe bar") is an attempt to launch the program "C:\\My" with the arguments "Programs\\foo.exe" and "bar". This command is likely to fail with an exception to indicate "C:\My" cannot be found.

The example Runtime.getRuntime().exec("\"C:\\My Programs\\foo.exe\" bar") is an attempt to launch the program "\"C:\\My". This command will fail with an exception to indicate the program has an embedded quote.

Applications that need to launch programs with spaces in the program name should consider using the variants of Runtime.exec that allow the command and arguments to be specified in an array.

Alternatively, the preferred way to create operating systems processes since JDK 5.0 is using java.lang.ProcessBuilder. The ProcessBuilder class has a much more complete API for setting the environment, working directory and redirecting streams for the process.

I could confirm that this bug also exist on Java 6u45:

====
"/path/to/my/project/"C:/MinGW/msys/1.0/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
/bin/sh: /path/to/my/project/C:/MinGW/msys/1.0/bin/make.exe: No such file or directory
make.exe": *** [.clean-impl] Error 127


CLEAN FAILED (exit value 2, total time: 651ms)
====
It would be smarter of Oracle to inform and tutor other companies & programmers beforehand to use ProcessBuilder instead of blatantly remove older ways of functionality in new updates and let others enjoy the annoying surprise.

This *could* be that mentioned change in java triggered this behavior, but this is something in between java and MinGW. 

As far as I know, this bug is reproducible with mingw only.

As a workaround one can set make command (in toolchain configuration) to "make.exe" (instead of "c:/msys/1.0/bin/make.exe").
 
Also Path environment variable should be set like:
Path=c:\msys\1.0\bin;c:\MinGW\bin
before starting nb...

What I see now is that when java invokes a process it encloses executable in quotes (introduced u21?). Maybe this is a normal case on Windows. But looks like this makes msys's make.exe to fail. There is no problem with starting make, but unfortunately generated makefiles uses recursive make invocation. So when make tries to start another instance of make (from within the makefile) it expects (I think so) to find msys-style paths (/c/msys/1.0/bin/make) in it's args[0]. As a fallback it can work with c:\msys\1.0\bin\make.exe, but fails to do so with "c:\msys\1.0\bin\make.exe". As a result it tries to join working directory with args[0] and exec this and... fails.

Simple experiment that demonstrates this from cmd.exe (without NB):

1) No quotes => works fine:
C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>c:\msys\1.0\bin\make.exe -f Makefile clean
/bin/make -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: Entering directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'
rm -f -r build/Debug
rm -f dist/Debug/MinGW-Windows/welcome_1.exe
make[1]: Leaving directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>


2) Fails with quotes:
C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>"c:\msys\1.0\bin\make.exe" -f Makefile clean
/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1/"c:/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
/bin/sh: /c/Documents: No such file or directory
make.exe": *** [.clean-impl] Error 127

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>



3) As a 'workaround' MAKE variable can be set:

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>set MAKE=/c/msys/1.0/bin/make

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>"c:\msys\1.0\bin\make.exe" -f Makefile clean
/c/msys/1.0/bin/make -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: Entering directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'
rm -f -r build/Debug
rm -f dist/Debug/MinGW-Windows/welcome_1.exe
make[1]: Leaving directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>

http://hg.netbeans.org/cnd-main/rev/890dceeffc85

Integrated into 'main-golden', will be available in build *201304242301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/890dceeffc85
User: Andrew Krasny <akrasny@netbeans.org>
Log: Bug #228730 - java 7 update 21 breaks build in NetBeans 7.3, 7.2, ...

Nominated for 7.3 patch2

*** Bug 228976 has been marked as a duplicate of this bug. ***

Verified in build 20130428. Please push into 7.3.1 branch.

Pushed into 7.3 release

By default NetBeans creates 4 toolchains: Cygwin, Cygwin_4.x, MinGW and MinGW_TDM.

Cygwin and Cygwin_4.x works nicely before and after fix
MinGW works nicely after fix
MinGW_TDM fails in both cases (MinGW_TDM is equal to MinGW)

In NetBeans 7.3 patch 2 I can't create new project via "C/C++ Project with Existing Sources" wizard (small Qt sample - calculator)

(In reply to comment #12)
> In NetBeans 7.3 patch 2 I can't create new project via "C/C++ Project with
> Existing Sources" wizard (small Qt sample - calculator)
Workaround:
 replace C:/MinGW/msys/1.0/bin/make.exe on make.exe in Tools|Options
 remove cygwin (if cygwin exist, then NetBeans will use cygwin's make in any case)

Verified in NetBeans 7.3 patch 2

Integrated into 'main-golden', will be available in build *201305170640* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2ff0794e14c5
User: Andrew Krasny <akrasny@netbeans.org>
Log: Addfix for Bug #228730 (See comment #11)

Additional fix is verified in trunk. MinGW_TDM is now working correctly.

*** Bug 227868 has been marked as a duplicate of this bug. ***

*** Bug 230140 has been marked as a duplicate of this bug. ***

*** Bug 229620 has been marked as a duplicate of this bug. ***

*** Bug 230352 has been marked as a duplicate of this bug. ***

This issue still seems to exist. I've tested it on JRE 7-u25 with netbeans 7.4beta, 7.3.1, and Dev 201308310001 Using Mingw-64 gcc 4.8.1 rev 5

"Makefile:115: recipe for target 'all' failed
process_begin: CreateProcess(NULL, /C/MingW64/mingw64/bin/make.exe -f CMakeFiles\Makefile2 all, ...) failed.
make (e=2): The system cannot find the file specified.

make: *** [all] Error 2


BUILD FAILED (exit value 2, total time: 57ms)"

It should be noted that I don't have mysys installed, I do have cygwin installed, and make is not in my path variable.

I can work around this by dumping my mingw version of make into the path and then just setting my make path to just "make.exe" but that is a bit annoying.

(In reply to cogman from comment #22)
> It should be noted that I don't have mysys installed, I do have cygwin
> installed, and make is not in my path variable.
> 
> I can work around this by dumping my mingw version of make into the path and
> then just setting my make path to just "make.exe" but that is a bit annoying.

Make may work right unless it is in the environment path variable, it is a requirement.

(In reply to MackSix from comment #23)
> (In reply to cogman from comment #22)
> > It should be noted that I don't have mysys installed, I do have cygwin
> > installed, and make is not in my path variable.
> > 
> > I can work around this by dumping my mingw version of make into the path and
> > then just setting my make path to just "make.exe" but that is a bit annoying.
> 
> Make may work right unless it is in the environment path variable, it is a
> requirement.

I mean to say, it may _not_ work right.

cogman,

this is not supported configuration. Please either install cygwin and use cygwin gcc/make or install mingw+msys and use make from msys..

I agree, that this is an issue and maybe it will be addressed, but not in this release.

=Andrew

I have installed JRE 1.7u25 and Netbeans 7.3.1 and MinGW64/MSYS.
This error still persists:

/bin/sh: /d/kaka/CppDynamicLibrary_1/D:/MSYS/bin/make.exe: No such file or directory
"/d/kaka/CppDynamicLibrary_1/"D:/MSYS/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make.exe": *** [.clean-impl] Error 127


CLEAN FAILED (exit value 2, total time: 201ms)

For some reason chains the project's dir with the MSYS's make dir.
Pls, fix it.

jogshy, 

have you tried proposed workarounds (comments 3,4,13)?
Could you, please, try with the latest dev build?

Waiting for user response.

I have the same problem - but ONLY WITH VCC4N  (OK with Mingw)

I have Java update 51 (current)windows 8 32 bit.  

c:\msys\1.0\bin.exe exists ;c:\MinGW\bin  (and no cygwin)

PATH

C:\Windows\System32>set path
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v
1.0\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\TortoiseGit\bin;C:\Program Files\Windows Kits
\8.0\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program f
iles\boost\;C:\Program Files\Common Files\Acronis\SnapAPI\;c:\msys\1.0\bin;c:\MinGW\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

mingw

"/C/msys/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make.exe[1]: Entering directory `/d/Documents/NetBeansProjects/Welcome_1'

VCC4n

"/d/Documents/NetBeansProjects/Welcome_1/"C:/msys/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
/bin/sh: /d/Documents/NetBeansProjects/Welcome_1/C:/msys/bin/make.exe: No such file or directory
make.exe": *** [.build-impl] Error 127

Base directory 

C:\MinGW\bin

C:\Users\Paul\AppData\Roaming\NetBeans\VCC4N_0.3.3_beta\tools

Both have the expected c:/msys/bin/make.exe as make tool (entering just make.exe is not allowed).

Both show the expected C++ compiler:

C:\MinGW\bin\g++.exe
C:\Users\Paul\AppData\Roaming\NetBeans\VCC4N_0.3.3_beta\tools\msvc_caller.exe

Versions show the expected Make Tool GNU Make 3.81 for both (and the expected compilers).

NetBeans 7.3 and 8 beta show this fatal problem.

> 
> Both have the expected c:/msys/bin/make.exe as make tool (entering just
> make.exe is not allowed).
> 

If your path is actually c:/msys/1.0/bin/make.exe then why do you have c:/msys/bin/make.exe in your NetBeans tool chain?

Corrected PATH and now is referring to c:\msys\bin\

and also tried changed version of GNU make with varying results.

This problem has disappeared, but another remains, again for VCC4N which is not finding
msvc_caller.conf which I have raised on sourceforge VCC4N wiki.

I am confused (especially with 3 machines, 3 OS, 3 version of Netbeans, 3 version of make, 3 version of Java : 1 working and 2 not working), but ...

Why did it work OK for MinGW, but failed to find make.exe correctly for VCC4N?

What is 'correct' version of make?

What is search path for make?

As a Microsofty what, where and why is a *nix "/usr/bin/make"?

But Thanks.

I spent many hours trying to get NB C/C++ 8.0 Beta to recognize a make program:

  http://forums.netbeans.org/viewtopic.php?p=155011

Even if there is no impediments as noted in this bug to NB recognizing and using make.exe, I understand that there are only some versions which are suitable.  So it can be a challenge finding an installer for MinGW or whatever which has a suitable make.exe.  These always install a whole set of other programs, but perhaps the user already has the compiler, debugger and library of their choice already installed, and just wants a make.exe which NB will work with.  These installers may dynamically choose which software to install, so a particular installer, typically identified in instructions by its URL, might produce good results one month and not the next.

Installers may or may not alter the Windows PATH environment variable.  These make.exe programs evidently need some DLLs, so there are path questions about where they are located too, with potential trouble if another DLL of the same name is on the PATH but is incompatible.

Perhaps a workaround to these problems, changing JVM behavior and quoting difficulties would be to create a make.exe program using NB-compatible source code as a single executable without any DLLs, and to patch a few lines of the source code to cope with argv[0] being quoted or not.  This make.exe could be placed in any location at all.  As far as I know, make.exe doesn't need to be compatible with any other build tools and there's no need for it to be 64 bits.  All it needs to do is satisfy NB's requirements, at least on a Windows system.

I realize this is several months old, but I have been fighting with this since installing NetBeans 8.0.1 recently here on a W7x64 machine.

What I found to fix the issue was to redefine:

MAKE=C:/util/msys/1.0/bin/make.exe
MKDIR=C:/util/msys/1.0/bin/mkdir.exe
RM=C:/util/msys/1.0/bin/rm.exe

...in a separate .mk file, for convenience, and simply include it at the bottom of the main project Makefile.

Defining MAKE fixed the hokey path problem, then it complained that mkdir and rm weren't available, so I defined them, and voila.

Now the only quirk is that it doesn't remember to add .exe extension to the output file in the dist tree, but *does* look for it to delete when cleaning. Somebody sure done screwed up on that one.

At any rate, this makes it all okay.

Looks like this is still occurring with 8.0.2 and Java 8u45.

Only in exotic cases. For example in custom toolchains. If you know easy case, then P1 should be filed.