[WinAPI] cmd.exe finden, um es zu starten

[Krishty]

Ich bin gerade ein Bisschen ratlos. Und zwar starte ich von einer GUI-Anwendung aus ein CMD-Skript und leite seine Ausgaben in meine GUI um. Das funktioniert auch so weit ganz gut, nur muss ich was fest verdrahten und fühle mich dabei unwohl:

Ich starte das Skript in einem separaten Prozess via CreateProcess(). Die Dokumentation dazu:

To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.

Und das ist falsch. Wenn ich als Anwendungsname nur cmd.exe übergebe, schlägt die Funktion mit ERROR_FILE_NOT_FOUND fehl! Ich muss C:\Windows\System32\cmd.exe übergeben. Und das stinkt mir.

Ich *könnte* den Weg gehen, den die Dokumentation nicht erwähnt, aber viele andere benutzen: Programmname leer lassen und cmd.exe in die Parameterliste packen. Dann laufe ich aber Gefahr, mit der Autokorrektur zu kollidieren, wobei Randfälle kaputtgehen.

Ich *könnte* auch GetSystemDirectory() nutzen, um den wahren Pfad von System32 auf dem Zielsystem zu lokalisieren. Aber verdammt, da muss es doch was Einfacheres geben!

Ideen? Mache ich was falsch, dass es bei mir nicht wie in der Dokumentation beschrieben funktioniert?

[DerAlbi]

%systemroot%\system32\cmd.exe

sollte ein eindeutiger pfad sein... nicht?

[B.G.Michi]

Wie wäre es mit %COMSPEC%?

[Krishty]

Beide muss ich erst via PathUnExpandEnvStrings() auflösen, aber dabei habe ich schon ein deutlich besseres Gefühl :)

[dot]

lpApplicationName ist für den Fall hier nicht brauchbar, weil das eben nicht die Suchpfade benutzt. Wieso nicht einfach cmd.exe im lpCommandLine String angeben? Alles ist besser, als die Suche nach der exe selbst zu implementieren. Ich versteh nicht ganz, wo genau das Problem mit dieser Autokorrektur liegen soll, "cmd.exe /c" ist nichtmal ein gültiger Dateiname...

[Krishty]

Naja, weil die Dokumentation explizit sagt, dass man es anders machen soll. Aber wenn das, was die Dokumentation sagt, sowieso nicht funktioniert, kann man wohl drauf pfeifen.

[Andi]

Geht die Doku evtl. davon aus das du in C:\Usres\benutzername\Desktop bist?

[Krishty]

Keine Ahnung. Habe keine Zeit oder Lust, sie zum vierten Mal zu lesen.

Wo wir gerade dabei sind: Kennt ihr die Regeln für Anführungszeichen, wenn man cmd Parameter für ein Skript übergibt?

Run a program and pass a Long Filename

    cmd /c write.exe "c:\sample documents\sample.txt"

Spaces in Program Path

    cmd /c ""c:\Program Files\Microsoft Office\Office\Winword.exe""

Spaces in Program Path + parameters

    cmd /c ""c:\Program Files\demo.cmd"" Parameter1 Param2

Spaces in Program Path + parameters with spaces

    cmd /k ""c:\batch files\demo.cmd" "Parameter 1 with space" "Parameter2 with space""

Ich würde das nicht als Regel abhaken (es ist einer der Wege, die erreichen, was man will), aber … WTF. Das hat mich eine halbe Stunde aufgehalten weil ich nicht auf doppelte Anführungszeichen gekommen bin. WTF.

Wenn ihr Programme testet: Legt einen Benutzeraccount an, der im Namen Leerzeichen, Sonderzeichen, und Punkt hat. Und so lang wie möglich ist, damit es bei MAX_PATH so richtig kracht. Ich wette, dass die Hälfte der Konsolenprogramme zu funktionieren aufhört.

[Andi]

Dies schon probiert?

Code: Alles auswählen

CreateProcess(NULL, "cmd /c .... ", ......)

Hab es selbst nicht ausprobiert!