Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Runtime.exec(String[])
21 views
Skip to first unread message
Sven Köhler
Dec 18, 2011, 1:35:38 PM12/18/11
to
Hi,
Es geht um die Funktion oben, und auch den ProcessBuilder.
Unter Windows sind beide Funktionen nicht "sicher". Mit "sicher" meine
ich, dass die Argumente nicht korrekt umgeformt werden, so dass sie
einer Kommandoteile entsprechen, wie sie z.B. durch CommandLineToArgv
unter Windows verarbeitet werden könnte.
Hintergrund: unter Windows werden einem Programm die Argumente als 1
String übergeben, nicht wie unter Unix als Array. D.h. wenn man ein
Array von Argumenten an ein Programm übergeben will, muss man die
Argumente vorher erst umarbeiten, wenn diese Leerzeichen enthalten, den
leeren String darstellen, oder Anführungszeichen enthalten, etc.
Ich bin darauf gestoßen, das sowohl Runtime.exec(String[]) als auch
ProcessBuilder den leeren String nicht in ein "" umsetzen. String mit
leerzeichen werden aber sowohl mit Anführungszeichen umgeben. So kommt
ein Leezeichen korrekt als " " in den Programmaufruf eingefügt. Der leer
String wird aber verschluckt.
Desweiteren versagen sowohl Runtime.exec(String[]) und ProcessBuilder
bei Argumenten welche Anführungszeichen enthalten. So wird das Argument
"a\"b" (<- Java String) als a"b in die Kommandozeile eingebettet und
nicht als "a\"b" wie es CommandLineToArgv erwarten würde.
Desweiteren habe ich festgestellt, dass ich die Argumente vorher manuell
mit Ausrufungszeichen versehen kann, und auch das escaping vorher
vornehmen kann, ohne dass Runtime.exec(String[]) neue Anführungszeichen
hinzufügt. D.h. es muss eine Art Überprüfung stattfinden, ob die
Argumente bereits in Anführungszeichen stehen, oder nicht.
Das alles scheint NICHT dokumentiert zu sein. Weder bei Runtime noch bei
ProcessBuilder. Beide verhalten sich demnach hochgradig
Platformunabhängig. Diverse Empfehlungen in diversen Foren (und bestimmt
auch hier) Runtime.exec(String[]) der anderen Variante
Runtime.exec(String) vorzuziehen, weil es "sicherer" sei, gelten demnach
höchstens für Unix (wo die Argumente so beim Programm ankommen wie man
sie in Runtime.exec(String[]) reinsteckt) nicht aber für Windows.
Ein Bugreport Richtung Oracle (über die alte Sun Bug Datenbank) führe zu
nichts. Er tauchte nicht mal im System auf. (Der Report ist schon Wochen
her).
Un Windows manuell einen String zusammenzubauen mit korrekt escapten
Ausrufungszeichen und allem pipapo und diesen an Runtime.exec(String) zu
übergeben scheint zu funktionieren. Obwohl auch dieses Feature (also
dass der String unmodifiziert an Windows weitergegeben wird) nicht
dokumentiert ist.
Im Moment sehe ich mich als Java Programmierer außerstande, einen
korrekten Aufruf eines externen Programms mit dem in der Doku
spezifizierten (oder nicht spezifizierten) Verhalten von Runtime.exec
und ProcessBuilder durchzuführen. Hurra!
Kennst jemand einen entsprechenden Eintrag in der Sun Bugdatenbank der
dieses Thema behandelt? Ich habe keinen gefunden. Gibt es (z.B. beim
OpenJDK) noch einen anderen Bugtracker? So bleiben kann es ja wohl nicht.
Grüße,
Sven
Es geht um die Funktion oben, und auch den ProcessBuilder.
Unter Windows sind beide Funktionen nicht "sicher". Mit "sicher" meine
ich, dass die Argumente nicht korrekt umgeformt werden, so dass sie
einer Kommandoteile entsprechen, wie sie z.B. durch CommandLineToArgv
unter Windows verarbeitet werden könnte.
Hintergrund: unter Windows werden einem Programm die Argumente als 1
String übergeben, nicht wie unter Unix als Array. D.h. wenn man ein
Array von Argumenten an ein Programm übergeben will, muss man die
Argumente vorher erst umarbeiten, wenn diese Leerzeichen enthalten, den
leeren String darstellen, oder Anführungszeichen enthalten, etc.
Ich bin darauf gestoßen, das sowohl Runtime.exec(String[]) als auch
ProcessBuilder den leeren String nicht in ein "" umsetzen. String mit
leerzeichen werden aber sowohl mit Anführungszeichen umgeben. So kommt
ein Leezeichen korrekt als " " in den Programmaufruf eingefügt. Der leer
String wird aber verschluckt.
Desweiteren versagen sowohl Runtime.exec(String[]) und ProcessBuilder
bei Argumenten welche Anführungszeichen enthalten. So wird das Argument
"a\"b" (<- Java String) als a"b in die Kommandozeile eingebettet und
nicht als "a\"b" wie es CommandLineToArgv erwarten würde.
Desweiteren habe ich festgestellt, dass ich die Argumente vorher manuell
mit Ausrufungszeichen versehen kann, und auch das escaping vorher
vornehmen kann, ohne dass Runtime.exec(String[]) neue Anführungszeichen
hinzufügt. D.h. es muss eine Art Überprüfung stattfinden, ob die
Argumente bereits in Anführungszeichen stehen, oder nicht.
Das alles scheint NICHT dokumentiert zu sein. Weder bei Runtime noch bei
ProcessBuilder. Beide verhalten sich demnach hochgradig
Platformunabhängig. Diverse Empfehlungen in diversen Foren (und bestimmt
auch hier) Runtime.exec(String[]) der anderen Variante
Runtime.exec(String) vorzuziehen, weil es "sicherer" sei, gelten demnach
höchstens für Unix (wo die Argumente so beim Programm ankommen wie man
sie in Runtime.exec(String[]) reinsteckt) nicht aber für Windows.
Ein Bugreport Richtung Oracle (über die alte Sun Bug Datenbank) führe zu
nichts. Er tauchte nicht mal im System auf. (Der Report ist schon Wochen
her).
Un Windows manuell einen String zusammenzubauen mit korrekt escapten
Ausrufungszeichen und allem pipapo und diesen an Runtime.exec(String) zu
übergeben scheint zu funktionieren. Obwohl auch dieses Feature (also
dass der String unmodifiziert an Windows weitergegeben wird) nicht
dokumentiert ist.
Im Moment sehe ich mich als Java Programmierer außerstande, einen
korrekten Aufruf eines externen Programms mit dem in der Doku
spezifizierten (oder nicht spezifizierten) Verhalten von Runtime.exec
und ProcessBuilder durchzuführen. Hurra!
Kennst jemand einen entsprechenden Eintrag in der Sun Bugdatenbank der
dieses Thema behandelt? Ich habe keinen gefunden. Gibt es (z.B. beim
OpenJDK) noch einen anderen Bugtracker? So bleiben kann es ja wohl nicht.
Grüße,
Sven
Sven Köhler
Dec 18, 2011, 1:53:27 PM12/18/11
to
Am 18.12.2011 19:35, schrieb Sven Köhler:
> Im Moment sehe ich mich als Java Programmierer außerstande, einen
> korrekten Aufruf eines externen Programms mit dem in der Doku
> spezifizierten (oder nicht spezifizierten) Verhalten von Runtime.exec
> und ProcessBuilder durchzuführen.
Den Teil muss ich teilweise wieder zurücknehmen. In der Doku von
> Im Moment sehe ich mich als Java Programmierer außerstande, einen
> korrekten Aufruf eines externen Programms mit dem in der Doku
> spezifizierten (oder nicht spezifizierten) Verhalten von Runtime.exec
> und ProcessBuilder durchzuführen.
ProcessBuilder findet sich folgende Anspielung auf Windows:
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.
Allerdings ist die Beschreibung dahingehend unvollständig, dass der
zweite String im Array nur dann unverändert an das OS (in diesem Fall
Windows) weitergeben wird, wenn er mit " und " endet. Ansonsten wird er,
wenn er Leerzeichen enthält, mit Anführungszeichen umgeben.
0 new messages