code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues

[Jeroen Frijters]

Hi,

I'm not a formal reviewer, but I've implemented this same thing for IKVM.NET which has to simulate the behavior of CreateProcess when running on Windows (because it uses the .NET API to start a process and that doesn't have this hack).

Your algorithm doesn't match CreateProcess, because that also takes into account various directories to search (the application's directory, the current directory, the system directory, the windows directory and the PATH).

Regards,
Jeroen

________________________________________
From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Michael McMahon [michael.x.mcmahon at oracle.com]
Sent: Tuesday, September 13, 2011 6:17 PM
To: core-libs-dev at openjdk.java.net
Subject: code review request: 7051946: Runtime.exec(String command) /   ProcessBuilder command parsing issues

Can I get the following webrev reviewed please?

http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/

The problem is when calling Runtime.exec(String) with a program name
containing
white space (on win32), it is difficult to distinguish between the
program name and
any parameters to it.

Eg. "C:\A B\C D\E foo bar".

Does this string represent the program name or are foo and bar
arguments to a program called E? And there are many other possibilities.

We just pass the whole string to windows and it does an ok job of
disambiguating according
to a defined algorithm. There are two problems however:

1) our security check doesn't do exactly the same thing as windows. So
we may end up checking for
a different file to what gets executed.

2) when the file doesn't exist, the error returned is truncated. In the
example above,
it would think C:\A is the non-existing program.

The problem doesn't occur on Solaris/Linux because those OSes never try
to disambiguate
the way windows does. So, there is currently already consistency between
the security check
and the path to be run. Effectively, this way of calling Runtime.exec()
never worked on those platforms
and you always had to use one of the other multi-arg methods.

So, the solution is first to refactor ProcessBuilder and ProcessImpl, by
moving the generation
of the exception down to ProcessImpl (when the file is not found) and
also to move the
security check down to ProcessImpl, where we can do the windows specific
checking,
and for Solaris and Windows there's no change in behavior beyond  that.

Thanks,
Michael.