exec problem is JDK 1.7.0_21

[Sven Köhler]

Am 27.04.2013 11:22, schrieb Steven Simpson:

Well, the first token can contain backslashes, but they are taken
literally.

I should haven written "can be assumed not to contain any quotes and
backslashes followed by a quote".

 

[Arne Vajhøj]

Tue, 16 Apr 2013 15:48:10 -0700, /Roedy Green/:

This code no longer works in JDK 1.7.0_21

Process p = exec( "F:\\Program Files (x86)\\netload\\netload.exe",
true/* wait */ );

I thought perhaps it wanted some embedded quotes, but that does not
work either.

Will experiment further.

Command works fine at the prompt.

You may also read in the release notes - "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.
[...]

Sometimes it is a good thing to read the release notes.

Arne

 

[Arne Vajhøj]

The specific case is broken. Now what?

ProcessBuilder provides some functionality.

If you need more or different functionality, then use JNI
to write your own stuff.

Running external processes is not really platform independent,
so you do not loose that.

Arne

 

[Arne Vajhøj]

Am 21.04.2013 14:08, schrieb Martin Gregorie:

True, from which you conclude, that the following does not apply to
Windows. That the documentation is dangerously vague - but that's
another issue.

We have some developers sitting and has to come up with the
documentation for this.

They know that Java runs on Windows, MacOS X, Linux, Solaris,
HP-UX, AIX, *BSD, OpenVMS, i/OS, z/OS etc.etc..

I can't really blame them for being a bit vague here.

They can describe some general issues and then the
developers using this API on platform XYZ need to test
carefully.

It is impossible for them to define a universal model
that will work on all platforms or to describe all
implementation specific quirks.

Arne

 

[Sven Köhler]

Am 28.04.2013 05:35, schrieb Arne Vajhøj:

ProcessBuilder provides some functionality.

Hmm. I find that argument dangerous, as it given the a free pass to
implement whatever they want - however badly they want ...

If you need more or different functionality, then use JNI
to write your own stuff.

.... and then claim

Running external processes is not really platform independent,
so you do not loose that.

Are you saying, that they should have never attempted to convert an
array of arguments into a command line string on Windows? Because that
would exactly be one of my points. Recall the fact, that documentation
already mentions the possibility of proper platform dependent behaviour.
Or are you somehow trying to defend the faulty escaping they implemented
to make it seem like a cross-platform API?

Because at the moment, we're stuck with something broken which is
neither platform dependent nor independent. We neither have a platform
dependent API (e.g. taking arrays of arguments on UNIX and a single
argument on Windows) and neither a platform independent API (which
properly converts an argument array to an argument string).


Regards,
Sven

 

[Sven Köhler]

My comment just meant what it said - identify the specific app on
Windows, the arguments it needs, and do what you need to do with
ProcessBuilder - in a way irrespective of official docs - to make it work.

OK, I've done that. In my case, it is possible to workaround the buggy
ProcessBuilder escaping - luckily. Now, in other cases it's actually
impossible, as ProcessBuilder will add quotes where they don't belong.
For the sake of argument, let's assume my case would be of the latter
type: I can't workaround ProcessBuilder's mangling of Strings. What do I
do now?

And why does this matter for the question, whether ProcessBuilder is
broken or not?



Regards,
Sven

 

[Arne Vajhøj]

Am 28.04.2013 05:35, schrieb Arne Vajhøj:

Hmm. I find that argument dangerous, as it given the a free pass to
implement whatever they want - however badly they want ...

I don't think they have intended to do it badly.

They decided to do things a certain way.

And that decision is causing some problem for you.

But that does not necesarrily make it a bad decision.

... and then claim


Are you saying, that they should have never attempted to convert an
array of arguments into a command line string on Windows? Because that
would exactly be one of my points. Recall the fact, that documentation
already mentions the possibility of proper platform dependent behaviour.
Or are you somehow trying to defend the faulty escaping they implemented
to make it seem like a cross-platform API?

Because at the moment, we're stuck with something broken which is
neither platform dependent nor independent. We neither have a platform
dependent API (e.g. taking arrays of arguments on UNIX and a single
argument on Windows) and neither a platform independent API (which
properly converts an argument array to an argument string).

I am saying that executing external commands is not platform
independent and that if you don't like the standard functionality,
then you should just create your own native code and call it
via JNI. Problem solved.

Arne