Kommandozeilenargumente in aufgerufenden Batchjobs verarbeiten

[sturzpilot]

Hallo,

ich habe folgendes Problem, bei dem ich trotz intensiver Websuche nicht weiterkomme und hoffe, dass mir jemand in diesem Forum vielleicht einen Tipp geben kann.

Ich möchte gerne von Java aus ein Windows-Programm aufrufen udn dabei Parameter übergeben, die dieses aufgerufene Programm verwenden soll. Dazu habe ich folgendes Programm geschrieben:

public static void main(String[] args) {
        try {
            Process pr = Runtime.getRuntime().exec("C:\\testdir\\batchjob.bat einArgument");
            pr.waitFor();
        } catch (Exception ex) {
        }
    }

Der Inhalt von batchjob.bat ist folgender:

echo "Im Folgenden die Aufrufparameter:" >> c:\testdir\log.txt
echo %1% >> c:\testdir\log.txt

Wenn ich nun das Programm aufrufe (java -jar DasErzeugteProgramm.jar), enthält die Ausgabedatei c:\testdir\log.txt nur die erste echo-Ausgabe, d.h.
Im Folgenden die Aufrufparameter:

Lasse ich in der batchjob.bat jedoch den absoluten Pfad bei der Ausgabeumleitung weg:
echo "Im Folgenden die Aufrufparameter:" >> log.txt
echo %1% >> log.txt

... so wird die Datei log.txt im Arbeitsverzeichnis korrekt geschrieben. D.h. sie hat den Inhalt
"Im Folgenden die Aufrufparameter:"
einArgument

Was passiert da? Kann das Argument nicht gelesen werden, wenn dieses in eine Datei mit absoluter Pfadangabe geschrieben werden soll?? ???:L

Und wenn das so ist, kann man das in den Policys irgendwo freischalten?

Zum Hintergrund: Ich habe es mit Java 1.6u21 und Java 1.7u7 auf Win XP ausprobiert. Das Verhalten war stets das gleiche.

Ich würde mich freuen, wenn mir jemand einen Hinweis geben könnte.

Gruß,

Stefan

 

[Empire Phoenix]

benutz processbuilder, der is wesentlich sauberer, und löst evtl deine probleme bereits, da es intern escapen und so krams amcht.

 

[sturzpilot]

Hallo,

vielen Dank für den Hinweis, aber leider ist das Verhalten absolut identisch. Ich habe den Code so umgeschrieben:

public static void main(String[] args) {
        try {
            ProcessBuilder pbuilder = new ProcessBuilder ("C:\\testdir\\batchjob.bat","einArgument");
            Process pb = pbuilder.start();
            pb.waitFor();
        } catch (Exception ex) {
            System.err.println("ex=" + ex);
        }
    }

... aber trotzdem wird der übergebene Parameter nur dann in ein log.txt geschrieben, wenn ich dessen absoluten Pfad weglasse.

Gruß,

Stefan

 

[Bernd Hohmann]

Es ist schon richtig, dass in Batches auf Variablen mit %variable% zugegriffen wird, das gilt aber nicht für die Kommandozeilen-Variablen %0 ...%9

Du musst also "echo %1 >> c:\testdir\log.txt" schreiben damit der Interpreter da keinen Murx zusammendichtet.

Sieht man schnell, wenn man das Batch mal standalone mit einem Parameter ausführt.

Bernd

 

[sturzpilot]

Hallo Bernd,

vielen Dank für die Antwort!! Das war die Lösung. :applaus:

Interessanterweise hatte ich das Batch vorher standalone mit Inhalt %1% aufgerufen und es hat funktioniert. In diesem Fall scheint die DOS-Shell also offenbar aus dem Übergabeparameter eine Umgebungsvariable zu füllen, die dann mit echo %1% ausgegeben werden kann. Und das kann natürlich nicht funktionieren, wenn das Java-Programm den Aufruf macht (dafür gibt es ja die Möglichkeit, explizit Umgebungswerte mit zu übergeben).

Jetzt frage ich mich nur noch, warum der Zugriff vorher per %1% funktioniert hat, wenn ich die Ausgabe in eine Datei ohne absoluten Pfad umleite. Aber es muss ja immer noch Geheimnisse geben...

Jedenfalls hilft mir deine Lösung, dass ich in meinem ursprünglichen Projekt weiterkomme. Vielen Dank!!

Gruß,

Stefan

 

[Bernd Hohmann]

Das irritiert mich jetzt. Unter XP wie auch Windows 7 macht er bei mir dieses hier:

T:\tmp>test.bat param1

T:\tmp>echo "Im Folgenden die Aufrufparameter:"  1>>t:\tmp\log.txt

T:\tmp>echo param1\tmp\log.txt
param1\tmp\log.txt

Da wird wohl durch das abschliessende % die Umleitung von Stdout in die Datei wegsubstituiert - das passiert aber interessanterweise nicht, wenn die Pfadangabe raus ist. Naja, die reine DOS-Shelll war schon immer eine etwas wunderliche Konstruktion

Bernd

 

[troll]

@bernd
ich finds witzig wie du dich in nem anderen thema aufregst das IT seit jahrzehnten nur von mist durchzogen ist (was darauf schließen lässt das du mindestens dieses alter + 20 oder so hast) und sagst selbst zum "command line intepreter" "dos-shell" ... OUCH ...
eigentlich bin ich von ausgegangen das gerade du wissen müsstest das es lediglich ein "befehlszeileninterpreter" ist und kein eigenständiges OS ... oder gar ein emulator für eines ...