Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23473 > unrolled thread

exec problem is JDK 1.7.0_21

Back to article view | Back to comp.lang.java.programmer

Contents

  exec problem is JDK 1.7.0_21 Roedy Green <see_website@mindprod.com.invalid> - 2013-04-16 15:48 -0700
    Re: exec problem is JDK 1.7.0_21 Lew <lewbloch@gmail.com> - 2013-04-16 16:48 -0700
    Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 13:00 +0300
    Re: exec problem is JDK 1.7.0_21 Joerg Meier <joergmmeier@arcor.de> - 2013-04-20 15:13 +0200
      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 19:07 +0300
        Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-20 09:24 -0700
          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 19:34 +0300
            Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-20 11:01 -0700
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:25 +0300
            Re: exec problem is JDK 1.7.0_21 Joerg Meier <joergmmeier@arcor.de> - 2013-04-20 22:03 +0200
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:29 +0300
                Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-20 21:56 +0000
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 08:31 +0300
                    Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 11:08 +0000
                      Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-21 13:43 -0300
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:12 +0300
                        Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 21:17 +0000
                        Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:49 -0400
                Re: exec problem is JDK 1.7.0_21 Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-20 15:03 -0700
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 08:26 +0300
                    Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-21 14:30 +0100
                      Re: exec problem is JDK 1.7.0_21 Knute Johnson <nospam@knutejohnson.com> - 2013-04-21 09:20 -0700
                        Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-21 11:31 -0700
                          Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-21 16:06 -0300
                            Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 19:47 +0000
                              Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 23:01 +0000
                        Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:29 +0300
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:45 +0300
                          Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 21:38 +0000
                          Re: exec problem is JDK 1.7.0_21 Knute Johnson <nospam@knutejohnson.com> - 2013-04-21 18:49 -0700
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-22 09:36 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-22 10:39 +0100
                                Re: exec problem is JDK 1.7.0_21 Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-22 07:43 -0700
                                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-22 19:33 +0300
                                    Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 07:30 +0100
                            Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-22 21:07 +0000
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:28 +0300
                                Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-23 21:05 +0000
                                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 11:22 +0300
                                    Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-24 20:22 +0000
                                  Re: exec problem is JDK 1.7.0_21 Nigel Wade <nmw@ion.le.ac.uk> - 2013-04-24 11:24 +0100
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:23 +0300
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:40 +0300
                Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 10:48 +0100
                  Re: exec problem is JDK 1.7.0_21 Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-04-23 13:31 +0300
                    <? extends String> (was: exec problem is JDK 1.7.0_21) Steven Simpson <ss@domain.invalid> - 2013-04-23 14:55 +0100
                      Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 16:37 +0100
                        Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 08:50 -0700
                          Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 17:30 +0100
                            Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 09:58 -0700
                              Re: <? extends String> Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-04-23 21:06 +0300
                              Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 19:33 +0100
                                Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 12:26 -0700
                                  Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-24 09:08 +0100
                          Re: <? extends String> Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-23 16:28 -0300
                      Re: <? extends String> (was: exec problem is JDK 1.7.0_21) Lew <lewbloch@gmail.com> - 2013-04-23 14:12 -0700
                        Re: <? extends String> Steven Simpson <ss@domain.invalid> - 2013-04-23 23:22 +0100
                  Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 19:56 +0100
                    Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:31 +0300
                      Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 23:39 +0100
                        Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 09:29 +0300
                          Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-24 10:26 +0100
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 13:11 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-24 22:24 +0100
                                Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:49 +0300
                                  Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 10:19 +0100
                            Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-25 09:02 +0100
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:47 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 09:50 +0100
                                Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 10:07 +0100
                                  Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-27 08:44 +0100
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-26 20:17 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-27 09:22 +0100
                                Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-27 12:39 +0300
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:17 +0300
                    Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-23 17:32 -0300
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 10:39 +0300
                        Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-25 09:02 +0100
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:59 +0300
                            Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-25 18:38 -0300
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-28 10:57 +0300
                        Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:35 -0400
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-28 09:23 +0300
                            Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 09:52 -0400
    Re: exec problem is JDK 1.7.0_21 Stanimir Stamenkov <s7an10@netscape.net> - 2013-04-20 17:52 +0300
      Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:31 -0400

Page 1 of 5  [1] 2 3 4 5  Next page →

#23473 — exec problem is JDK 1.7.0_21

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.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computer programming is the best remedy for pain (physical or emotional) 
I have encountered. It requires so much concentration there is nothing left 
over to pay attention to the pain. They should teach this in AA.

[toc] | [next] | [standalone]

#23475

Roedy Green wrote:
> 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.

What about 

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

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

Process p = exec( "F:/Progra~1/netload/netload.exe", true);
?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#23518

Am 17.04.2013 01:48, schrieb 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 */ );

Which kind of exec method is that? The standard ones don't take a
boolean paramater.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23520

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

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

No need: just read the change notes for the update:

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

---------8<---------

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.

---------8<---------

Specifically, you use a path with a space in it. Frankly, I'm surprised
that ever worked. That being said, this seems to be a step back, not
forward.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#23529

Am 20.04.2013 16:13, schrieb Joerg Meier:
> Specifically, you use a path with a space in it. Frankly, I'm surprised
> that ever worked. That being said, this seems to be a step back, not
> forward.

I have a question for everybody here:

What would you expect
  new ProcessBuilder("c:\test.exe", "a b").start();
to do on Windows?

Read the documentation of ProcessBuilder very careful.
In particular this passage:

> a command, a list of strings which signifies the external program
> file to be invoked and its arguments, if any. Which string lists
> represent a valid operating system command is system-dependent. For
> example, it is common for each conceptual argument to be an element
> in this list, but there are operating systems where programs are
> expected to tokenize command line strings themselves - on such a
> system a Java implementation might require commands to contain
> exactly two elements
http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html


What is should do:
1) It should pass the command line parameter string "a b" to the program
test.exe. Note: on Windows, command line parameters are a single string
- there is no array as on UNIX.
2) What Java currently does: Since "a b" contains spaces, Java adds
quotes to it. Hence, the parameter string that test.exe sees is "\"a
b\"" which is wrong.
3) Workaround: use "\"a\" \"b\"" instead of "a b" because Java doesn't
add quotes if the first and last character are quotes.


The current implementation of ProcessBuilder for Windows is simply broken.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23530

On 4/20/2013 9:07 AM, Sven Köhler wrote:
> What would you expect
>    new ProcessBuilder("c:\test.exe", "a b").start();
> to do on Windows?

> 2) What Java currently does: Since "a b" contains spaces, Java adds
> quotes to it.

Which is correct, because if you wanted two separate arguments, you 
would have read the docs and given the process builder two separate 
arguments.

     new ProcessBuilder("c:\\test.exe", "a", "b").start();

Note also that "\t" is Java escape for tab, so you didn't get either 
argument correct, unless you had a Windows executable with a tab as the 
first character.

[toc] | [prev] | [next] | [standalone]

#23531

Am 20.04.2013 19:24, schrieb markspace:
> Which is correct, because if you wanted two separate arguments

Well, you should have read the part of the documentation I quoted.
Windows is one of the operating systems, where programs tokenize the
command line parameters by themselves - in which case the array passed
to the ProcessBuilder should contain exactly two elements. q.e.d.

[toc] | [prev] | [next] | [standalone]

#23534

On 4/20/2013 9:34 AM, Sven Köhler wrote:
> Am 20.04.2013 19:24, schrieb markspace:
>> Which is correct, because if you wanted two separate arguments
>
> Well, you should have read the part of the documentation I quoted.
> Windows is one of the operating systems, where programs tokenize the
> command line parameters by themselves - in which case the array passed
> to the ProcessBuilder should contain exactly two elements. q.e.d.
>

Uh, but the ProcessBuilder is obviously preventing tokenization by 
putting quotes around the argument, because you only used one parameter....

[toc] | [prev] | [next] | [standalone]

#23539

Am 20.04.2013 21:01, schrieb markspace:
> On 4/20/2013 9:34 AM, Sven Köhler wrote:
>> Am 20.04.2013 19:24, schrieb markspace:
>>> Which is correct, because if you wanted two separate arguments
>>
>> Well, you should have read the part of the documentation I quoted.
>> Windows is one of the operating systems, where programs tokenize the
>> command line parameters by themselves - in which case the array passed
>> to the ProcessBuilder should contain exactly two elements. q.e.d.
> 
> Uh, but the ProcessBuilder is obviously preventing tokenization by
> putting quotes around the argument, because you only used one parameter....

How would you propose to pass two arguments to a program on Windows, if
the documentation clearly states, that one should pass an array with
exactly two elements to the ProcessBuilder constructor?


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23538

On Sat, 20 Apr 2013 19:34:15 +0300, Sven Köhler wrote:

> Am 20.04.2013 19:24, schrieb markspace:
>> Which is correct, because if you wanted two separate arguments
> Well, you should have read the part of the documentation I quoted.
> Windows is one of the operating systems, where programs tokenize the
> command line parameters by themselves - in which case the array passed
> to the ProcessBuilder should contain exactly two elements. q.e.d.

ProcessBuilder acts exactly the way Windows needs it to:

C:\Users\Maya>dir "c:\Program Files\Java"
 Volume in drive C has no label.

 Directory of c:\Program Files\Java

10/03/2012  09:55 PM    <DIR>          .
10/03/2012  09:55 PM    <DIR>          ..
10/03/2012  09:55 PM    <DIR>          jdk1.7.0_07
03/31/2013  12:46 PM    <DIR>          jre7
               0 File(s)              0 bytes
               4 Dir(s)  10,930,348,032 bytes free

C:\Users\Maya>dir c:\Program Files\Java
The system cannot find the file specified.

If you want to supply a single argument that contains a space under
Windows, it needs to be surrounded by quotes. Which is exactly what
ProcessBuilder does.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#23540

Am 20.04.2013 23:03, schrieb Joerg Meier:
> If you want to supply a single argument that contains a space under
> Windows, it needs to be surrounded by quotes. Which is exactly what
> ProcessBuilder does.

I ask you the same question that I asked markspace:
How would you propose to pass two arguments to a program on Windows, if
the documentation clearly states, that one should pass an array with
exactly two elements to the ProcessBuilder constructor?
(The first element of course being the program name)

[toc] | [prev] | [next] | [standalone]

#23542

On Sun, 21 Apr 2013 00:29:47 +0300, Sven Köhler wrote:

> Am 20.04.2013 23:03, schrieb Joerg Meier:
>> If you want to supply a single argument that contains a space under
>> Windows, it needs to be surrounded by quotes. Which is exactly what
>> ProcessBuilder does.
> 
> I ask you the same question that I asked markspace:
> How would you propose to pass two arguments to a program on Windows, if
> the documentation clearly states, that one should pass an array with
> exactly two elements to the ProcessBuilder constructor?
> (The first element of course being the program name)

Where do you get the two elements bit? My documentation (Java 6 Javadocs) 
says you can pass either a List<String> list of items or one or more 
Strings. Neither form requires exactly two elements. The only requirement 
is that the first element must be the command name and the rest are the 
arguments you're passing to it. If you're not looking at the Javadocs 
documentation set for the JDK or JRE you using, then you're working from 
incorrect information.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#23545

Am 21.04.2013 00:56, schrieb Martin Gregorie:
> Where do you get the two elements bit? My documentation (Java 6 Javadocs) 
> says you can pass either a List<String> list of items or one or more 
> Strings. Neither form requires exactly two elements. The only requirement 
> is that the first element must be the command name and the rest are the 
> arguments you're passing to it. If you're not looking at the Javadocs 
> documentation set for the JDK or JRE you using, then you're working from 
> incorrect information.

Start reading from the top of the page:
http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html

The first bullet points explains, that on some operating systems (e.g.
Windows), a valid command exist of exactly two Strings.

The constructor of ProcessBuilder on the other hand states that it does
not check whether the provided list of strings is a valid command.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23549

On Sun, 21 Apr 2013 08:31:14 +0300, Sven Köhler wrote:

> Am 21.04.2013 00:56, schrieb Martin Gregorie:
>> Where do you get the two elements bit? My documentation (Java 6
>> Javadocs)
>> says you can pass either a List<String> list of items or one or more
>> Strings. Neither form requires exactly two elements. The only
>> requirement is that the first element must be the command name and the
>> rest are the arguments you're passing to it. If you're not looking at
>> the Javadocs documentation set for the JDK or JRE you using, then
>> you're working from incorrect information.
> 
> Start reading from the top of the page:
> http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html
> 
> The first bullet points explains, that on some operating systems (e.g.
> Windows), a valid command exist of exactly two Strings.
>
It says *some* operating systems. No mention of Windows. It also says
"there are operating systems where programs are expected to tokenize 
command line strings themselves" which is not Windows IME - the C, C++ 
and Java CLI programming interface is the same for these in UNIX, Linux, 
OS-9 and Windows. There are probably some programming languages/
environments in which you'd be required to split out the CLI arguments 
yourself (IIRC TAL on a Guardian NonStop system is one), but if you're 
programing in that sort of environment then you'd be familiar with that 
sort of CLI parsing and expect to do it.

> The constructor of ProcessBuilder on the other hand states that it does
> not check whether the provided list of strings is a valid command.
>
Of course. Its perfectly reasonable to expect the OS to determine whether 
the first argument identifies a an executable file - every oyhet language 
system (e.g. all the C standard library exec() functions work that way), 
just as all command line arguments are passed to the called executable 
for validation.

In short, if you've tried something like this:

ProcessBuilder pb = new ProcessBuilder("cmnd.exe", "arg1", "arg2", 
"arg3"); 
pb.start();

and it doesn't work, try this:

ProcessBuilder pb = new ProcessBuilder("cmnd.exe", "arg1 arg2 arg3");
pb.start();

And for simplicity first try these with a program that is the equivalent 
of:

public class Tester
{
   public static main(String args)
   {
      for (int i = 0; i < args.length; i++)
         System.out.println(args[i]);
   }
}

but written is written in the same language as the program(s) you want to
run with ProcessBuilder. What results did you see? 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#23552

On 04/21/2013 08:08 AM, Martin Gregorie wrote:
> On Sun, 21 Apr 2013 08:31:14 +0300, Sven Köhler wrote:
>
>> Am 21.04.2013 00:56, schrieb Martin Gregorie:
>>> Where do you get the two elements bit? My documentation (Java 6
>>> Javadocs)
>>> says you can pass either a List<String> list of items or one or more
>>> Strings. Neither form requires exactly two elements. The only
>>> requirement is that the first element must be the command name and the
>>> rest are the arguments you're passing to it. If you're not looking at
>>> the Javadocs documentation set for the JDK or JRE you using, then
>>> you're working from incorrect information.
>>
>> Start reading from the top of the page:
>> http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html
>>
>> The first bullet points explains, that on some operating systems (e.g.
>> Windows), a valid command exist of exactly two Strings.
>>
> It says *some* operating systems. No mention of Windows. It also says
> "there are operating systems where programs are expected to tokenize
> command line strings themselves" which is not Windows IME - the C, C++
> and Java CLI programming interface is the same for these in UNIX, Linux,
> OS-9 and Windows. There are probably some programming languages/
> environments in which you'd be required to split out the CLI arguments
> yourself (IIRC TAL on a Guardian NonStop system is one), but if you're
> programing in that sort of environment then you'd be familiar with that
> sort of CLI parsing and expect to do it.
>
>> The constructor of ProcessBuilder on the other hand states that it does
>> not check whether the provided list of strings is a valid command.
>>
> Of course. Its perfectly reasonable to expect the OS to determine whether
> the first argument identifies a an executable file - every oyhet language
> system (e.g. all the C standard library exec() functions work that way),
> just as all command line arguments are passed to the called executable
> for validation.
>
> In short, if you've tried something like this:
>
> ProcessBuilder pb = new ProcessBuilder("cmnd.exe", "arg1", "arg2",
> "arg3");
> pb.start();
>
> and it doesn't work, try this:
>
> ProcessBuilder pb = new ProcessBuilder("cmnd.exe", "arg1 arg2 arg3");
> pb.start();
>
> And for simplicity first try these with a program that is the equivalent
> of:
>
> public class Tester
> {
>     public static main(String args)
>     {
>        for (int i = 0; i < args.length; i++)
>           System.out.println(args[i]);
>     }
> }
>
> but written is written in the same language as the program(s) you want to
> run with ProcessBuilder. What results did you see?
>
>
Great advice, you and Chris Uppal both. Every time I've had to run an 
external program from Java (well, from anything) as an executable, it's 
usually an OS-specific and app-specific thing. In each case I more or 
less end up doing what you guys suggest: experimentation.

On one long-running set of related projects that's lasted over a year 
now, this process of experimentation was even more extensive. The 
problem involved accessing PostgreSQL data on a RHEL Linux box that 
required SSH, with password. The access was/is from an ESB, Java-based.

To date I've found that tunneling and port forwarding works in some 
situations, with the ssh command and Expect, in other cases it was 
easier to use 'ssh' and 'empty' and to execute scripts on both the 
client and DB server. These were all ProcessBuilder situations.

But in one situation the experiments made it clear that JSch was the 
most reliable, dispensing with ProcessBuilder entirely.

In all of these cases I was able to discern what arguments were being 
received by various targets, and that's what matters. That's what you 
work with.

AHS

[toc] | [prev] | [next] | [standalone]

#23556

Am 21.04.2013 14:08, schrieb Martin Gregorie:
> It says *some* operating systems. No mention of Windows.

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

> It also says
> "there are operating systems where programs are expected to tokenize 
> command line strings themselves" which is not Windows IME - the C, C++ 
> and Java CLI programming interface is the same for these in UNIX, Linux, 
> OS-9 and Windows.

That is just wrong!

If you use the main method instead of the WinMain as an entry point in
your programs, that is just fine. But that the CRT does the tokenization
for you, doesn't mean that the program doesn't do the tokenization by
itself. It does. This becomes even more clear, if one compares the
native Windows API (i.e. CreateProcess) for launching programs to the
unix equivalents like execv.

[toc] | [prev] | [next] | [standalone]

#23560

On Sun, 21 Apr 2013 23:12:22 +0300, Sven Köhler wrote:

> Am 21.04.2013 14:08, schrieb Martin Gregorie:
>> It says *some* operating systems. No mention of Windows.
> 
> True, from which you conclude, that the following does not apply to
> Windows. That the documentation is dangerously vague - but that's
> another issue.
> 
>> It also says "there are operating systems where programs are expected
>> to tokenize command line strings themselves" which is not Windows IME -
>> the C, C++ and Java CLI programming interface is the same for these in
>> UNIX, Linux,
>> OS-9 and Windows.
> 
> That is just wrong!
>
Both Knute and I have code showing that ProcessBuilder does what we said 
it does. We have written code that shows it doing exactly what we told 
you it does, but you have only assertions without even a fragment of code 
for us to look at.

IOW, its money where your mouth is time. Show us code you've written that 
demonstrates it doing something else. That means posting both the Java 
SSCE that calls ProcessBuilder *AND* code for the program that it calls. 
Tomorrow will be ok, though tonight would be better.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#23685

On 4/21/2013 4:12 PM, Sven Köhler wrote:
> Am 21.04.2013 14:08, schrieb Martin Gregorie:
>> It says *some* operating systems. No mention of Windows.
>
> 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

[toc] | [prev] | [next] | [standalone]

#23543

On 4/20/13 2:29 PM, Sven Köhler wrote:
> Am 20.04.2013 23:03, schrieb Joerg Meier:
>> If you want to supply a single argument that contains a space under
>> Windows, it needs to be surrounded by quotes. Which is exactly what
>> ProcessBuilder does.
>
> I ask you the same question that I asked markspace:
> How would you propose to pass two arguments to a program on Windows, if
> the documentation clearly states, that one should pass an array with
> exactly two elements to the ProcessBuilder constructor?
> (The first element of course being the program name)
>
I think you've misinterpreted the documentation.

<http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html>

The first element of the array is the process name, the *rest* of the 
elements are each exactly one parameter.

The documentation says some *programs* may tokenize the argument 
themselves. If you are passing to such a program, then you need to use 
exactly two element array.

[toc] | [prev] | [next] | [standalone]

#23544

Am 21.04.2013 01:03, schrieb Daniel Pitts:
> The first element of the array is the process name, the *rest* of the
> elements are each exactly one parameter.
> 
> The documentation says some *programs* may tokenize the argument
> themselves. If you are passing to such a program, then you need to use
> exactly two element array.

The documentation speaks of "operating systems where programs are
expected to tokenize command line strings themselves". Windows is that
type of operating systems. For that type of operating system, the list
of strings shall contain exactly two elements.

Here's the quote again:

> a command, a list of strings which signifies the external program
> file to be invoked and its arguments, if any. Which string lists
> represent a valid operating system command is system-dependent. For
> example, it is common for each conceptual argument to be an element
> in this list, but there are operating systems where programs are
> expected to tokenize command line strings themselves - on such a
> system a Java implementation might require commands to contain
> exactly two elements
Source:
http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html

And in fact, I can confirm that ProcessBuilder passes the second element
of the string list to the invoked external program - however only if the
argument starts and ends with a quote.

Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web