Immer den exit-code von einer Anwendung gestartet wird mit "cmd" und "start" - Befehle

Ich habe eine Konsole-Anwendung. Die Interaktion mit dieser Anwendung erfolgt über TCP/IP.

Ich habe auch ein test-framework für Sie, das ist im Grunde eine Sammlung von BATCH-Skripten (...nicht meine Schuld). Was dieser test framework wird für jeden test ist im Grunde so aus:

  1. start /min "myapplication.exe" und warten Sie, bis die überprüfung empfangen wird, dass die Anwendung betriebsbereit ist.
  2. senden von Befehlen über TCP/IP zu dieser Anwendung erhalten Sie Ihre Antworten, und überprüfen Sie, ob die timings und die Werte Stimmen mit dem, was erwartet wird, von der konkrete test.

Ein problem, ich bin derzeit noch ist, dass die Anwendung beendet vorzeitig aufgrund einiger interner Fehler. Ich möchte unterscheiden zwischen der fehlgeschlagenen tests und die Anwendung zum Absturz zu bringen. Die einzige Angabe, die ich für diese, ist die Anwendung der exit-code.

So, ich habe versucht, die folgenden:

start /min cmd /c "myapplication.exe || echo %errorLevel% > exitcode.txt"

und dann später in den test-Skripten,

if exist exitcode.txt (
    set /p exitcode=<exitcode.txt
    echo ERROR: myapplication.exe returned exitcode %exitcode%.
    goto error
) else (
    goto do_processing
)

aber aus irgendeinem seltsamen Grund, die text-Datei nicht angezeigt wird, obwohl ich manchmal ein dialog über die Anwendung Abstürzen, und obwohl ich zwangsweise machen es nicht mit einem bekannten nicht-null exit-code. Der test geht nur durch do_processing und (natürlich) zum Misserfolg.

BEARBEITEN
Wenn ich

start /min cmd /c "nonsense || echo %errorLevel% > test.txt"

Ich manchmal erhalten eine text-Datei, die den string 9009, aber auch andere Zeiten, die text-Datei enthält die Zeichenfolge 0 oder manchmal 1, ...Was zum...?!

EDIT2
Wenn Sie

cmd /k "nonsense || echo %errorLevel%"

(Hinweis: die /k option), sehen Sie 0 gedruckt in dem neuen Fenster, aber wenn Sie dann geben Sie echo %errorlevel% erhalten Sie 1....

Ich wusste batch war nicht sehr gesund, aber es sollte zumindest konsequent wahnsinnig...

Irgendwelche Ideen auf, was könnte hier Los?

Sie müssen verwenden Sie das /wait-option, um einen exit-code. Was sollte besiegen den Punkt der Anwendung beginnen in den ersten Platz. Vermeidung von Feuer-und-vergessen werden, wenn die Fehlerprüfung erforderlich ist.
Passant: ich denke, das wird nicht funktionieren, weil, wenn Sie verwenden start die der exit-code wird nicht an das aufrufende Skript. Sollten Sie verwenden call statt. Es verhält sich wie start /wait aber übergibt Variablen. Überprüfen Sie dies: stackoverflow.com/questions/13257571/...
aber start /wait bedeutet, dass die Skript-Ausführung blockiert werden. Das Skript kann dann nicht gehen, um Feuer Befehle an...
Ich rief starten (in der Lage sein, um den hintergrund der Aufgabe) in Kombination mit cmd - (in der Lage sein zu Problem 2 Befehle, die ausführbar ist, plus das echo, dass sich die Ausgaben in Datei).

InformationsquelleAutor Rody Oldenhuis | 2015-02-04

  1. 11

    Normalen expansion wie %errorLevel% tritt auf, wenn die Anweisung wird geparst, und die gesamte CMD /C Befehl-Linie wird analysiert, in einem pass, also der Wert, den Sie bekommen, ist der Wert, der Bestand, bevor die Befehle ausgeführt wurden (immer 0).

    Erhalten Sie eine genauere Erklärung zu https://stackoverflow.com/a/4095133/1012053. Es kann schwierig sein, zu Folgen und zu verstehen, die Bedeutung der Phasen auf den ersten, aber es ist die Mühe Wert.

    Um Ihr problem zu lösen müssen Sie die Verzögerung der expansion der Variablen erst nachdem die exe ausgeführt wurde.

    Haben Sie zwei Möglichkeiten:

    Option 1) CALL Verwenden, um eine verzögerte Runde der expansion.

    In eine batch-Datei, die Sie würde die doppelte Prozente. Aber die Befehle ausführen mit CMD /C sind, laufen Sie unter einer Befehlszeile Kontext, keine batch. Die Verdoppelung der Prozente, nicht unter der command line.

    Statt dessen müssen Sie sich vorstellen, ein caret-Zeichen (cmd.exe escape-Zeichen) in den Namen der variable. Die erste phase der expansion erfolgt, bevor entweicht verarbeitet werden, so sieht es für einen Namen mit dem caret-Zeichen, und nicht gefunden. Wenn nicht gefunden, wird das command-line-parser bewahrt die ursprüngliche text, wenn die variable nicht gefunden wurde. Neben den Sonderzeichen behandelt werden und die Flucht verbraucht wird. Also, wenn der ANRUF Runde der expansion erfolgt, so sieht es die richtigen Variablennamen.

    start /min cmd /c "myapplication.exe || call echo %^errorLevel% > exitcode.txt"

    Ich glaube, du bist der Erteilung der START-Befehl innerhalb einer batch-script, so müssen Sie auch die doppelte Prozente zu verhindern, dass das übergeordnete batch-Skript von der Erweiterung ERRORLEVEL.

    start /min cmd /c "myapplication.exe || call echo %%^errorLevel%% > exitcode.txt"

    Option 2) Verwenden Sie verzögerte Erweiterung

    Verzögerte Erweiterung die syntax ist !errorlevel! statt %errorlevel%. Aber bevor Sie es verwenden können, verzögerte Erweiterung muss aktiviert sein. In einem batch-Skript, das Sie verwenden würden setlocal enableDelayedExpansion, aber das funktioniert nicht in einer Befehlszeile Kontext. Stattdessen müssen Sie die cmd.exe /v:on option.

    Vorausgesetzt, Ihre batch-Skript ist nicht aktiviert verzögerte Erweiterung, würde dann verwenden Sie einfach die folgende:

    start /min cmd /v:on /c "myapplication.exe || echo !errorLevel! > exitcode.txt"

    Aber wenn Sie Ihre batch-Skript muss aktiviert verzögerte Erweiterung, dann müssen Sie die Flucht der ! so, dass die übergeordnete batch-script nicht erweitern ERRORLEVEL. Beachten Sie, dass Sie müssen weiterhin verwenden /v:on weil die gestarteten sub-Prozess (meist) standardmäßig deaktiviert die verzögerte Erweiterung.

    start /min cmd /v:on /c "myapplication.exe || echo ^!errorLevel^! > exitcode.txt"
    AAAAAARGH! Ich kann nicht glauben, ich fiel für dieses mal wieder!! Dies löst es schön, ich danke Ihnen sehr. Ach, denke an die Kopfschmerzen verursacht hat bei so vielen Menschen...
    nur aus Neugier: gibt es irgendeinen Vorteil/Nachteil call vs. cmd /v:on?
    In diesem Fall, nicht wirklich. RUFEN Sie vergleichsweise sehr langsam, aber das kommt erst ins Spiel, wenn viele Iterationen innerhalb einer engen Schleife - nicht ein Problem hier. RUFEN Sie auch verheerende Auswirkungen auf die zitierte carets soll passieren (verdoppelt), nicht wieder ein Problem. Verzögerte Erweiterung verdirbt Erweiterung FÜR Variablen, deren Wert enthält ! Charakter, auch nicht ein problem hier.
    Etwas ist immer noch nicht ganz wie es sollte..., wenn die Bedingung Eintritt (Anwendung stürzt ab), die text-Datei geschrieben wird in beiden Optionen, die Sie Gaben. Allerdings mit option 1) es enthält "ECHO is on.", und mit option 2) Sie enthält "0"...nicht sicher, ob es eine Rolle spielt, aber die start Aufruf innerhalb einer if (...), das sich in einer batch-Datei, die called aus einer anderen batch-Datei, das hat setlocal EnableDelayedExpansion

    InformationsquelleAutor dbenham

  2. 1

    Erläutert hier verwenden Sie call statt start zu können, bewerten Sie die exit-codes. call starten Sie den Skript in die gleiche variable Umwelt in der Erwägung, dass gestartet wird, führen Sie es in einer neuen, der ist nicht erreichbar aus dem ersten Skript.

    ...aber der exit-code wird geschrieben, um eine Datei in der gleiche Vorgang, so dass ich nicht haben, um sich über die speziellen Variablen-Umgebung...
    Schreiben Sie die exit-code mit @echo %errorlevel% >> output.txt. Und dies ist der Grund, warum Sie nicht verwenden können start. start gewann nicht zugänglich ist %errorlevel% in der aufrufenden Skript. Mit start können Sie führen Sie den test im hintergrund, aber Sie werden nie Zugang zu der exit-code.
    Oh, sorry, hab ich missverstanden Sie.
    Das ist, warum ich verwenden start /min cmd /c "myapplication.exe || echo %errorLevel% > exitcode.txt". Starten, dann startet ein cmd mit seinen eigenen Variablen-Umgebung, die die Anwendung ausführt und (bedingt) Ausgänge alle nicht-null exit-code-Datei.
    Ja, sorry, der ursprüngliche Titel war vielleicht irreführend.

    InformationsquelleAutor MichaelS

  3. 1

    Andere Lösung kann sein zu verwenden & statt ||

    start myapplication.exe ^& echo %errorLevel% ^> exitcode.txt

    Den ^ ist ein escape-char, damit dieser ausgewertet wird innerhalb des start-und nicht außerhalb, wie Sie erklärt hier.

    Dieser arbeitete für mich. Hoffe, es hilft jemand.

    InformationsquelleAutor AxelWass

Schreibe einen Kommentar