Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?ISO-8859-1?Q?Sven_K=F6hler?= Newsgroups: comp.lang.java.programmer Subject: Re: exec problem is JDK 1.7.0_21 Date: Thu, 25 Apr 2013 11:47:45 +0300 Lines: 54 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.dfncis.de FFjTB80mvZJlTHQFR+G9lwfz4MVlV5v7ImNCKXWPxWoctdQfjubl5UTWV8 Cancel-Lock: sha1:ABQ5JIvIuvHEzJl6Og+AXGIA3JQ= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:23640 On 04/25/2013 11:02 AM, Chris Uppal wrote: > Steven Simpson wrote: > >> Cross-compiled with mingw32: > ... >> int main(void) > > What is doing the argument splitting here, and where is its spec ? Here's the spec of what microsoft implements: [1] http://msdn.microsoft.com/en-us/library/a1y7w461.aspx > Point is that when you start an executable on Windows /you do not pass an array > of strings/ to the OS. You pass a single string (or rather two strings -- one > to name the executable and the other to be the /entire/ command line). Exactly! > That means that the interpretation of that (single) string as an array of > sub-strings is /entirely/ at the target application's discretion. And hence > entirely arbitrary. Arbitrary in practise I mean, not just in theory. (I > have a micro-application in production that recognises quotes around its first > argument but not around its second ;-) And hence the current ProcessBuilder behavior is simply broken. > /Some/ applications use the built-in CommandLineToArgvW() function in Windows, I'm afraid, that has turned out to be false information. Executable generated by Microsoft compilers seem to use some other code, that follows the spec given in [1], but CommandLineToArgvW does not follow this specification. In fact, CommandLineToArgvW doesn't do anything useful. Let's forget I ever mentioned it. > but most (at least as far as my knowledge goes) do not. And anyway that > function's defined behaviour defies belief (clearly the documentation simply > enshrines the existing behaviour of some seriously stupid code). > ProcessBuilder (if we take the code rather than the documentation as the spec) > is a disgrace (if we just take the doc as the spec then it isn't even that). Yes. > I have no idea what command-line parser mingw32 provides for (imposes on) the > code it compiles. It /may/ be the same as CommandLineToArgvW() (or even be > implemented using it), but my guess is that the mingw folk will have come up > with something closer to what /bin/sh does in *nix. I would hope, that mingw32 and mingw64 toolchains have code that is compatible to [1]. At least my experience with mingw and visual studio executables is consistent with [1]. Regards, Sven