Direkt zum Inhalt

CMD-Kompatibilität und CMDebug / TCC-RT, Teil 1

Das Ziel unseres neuen eigenständigen Batch-Debuggers CMDebug besteht darin, CMD.EXE-Batchdateien mit möglichst nahezu 100-prozentiger Kompatibilität auszuführen. Ich habe Benutzer gebeten, mir alle CMD-Batchdateien zu senden, die sie gefunden haben und in denen sie nicht richtig funktionierten TCC.

Ein Benutzer hat eine Microsoft-Batchdatei gesendet, die nicht ausgeführt werden konnte TCC (und hat ein paar mir bisher unbekannte Fehler (Unfeatures?) in CMD.EXE aufgedeckt).

Das erste Problem lag in der Art und Weise, wie sie den internen SET-Befehl aufgerufen haben. Aus unbekannten Gründen hat sich der Entwickler dafür entschieden, die SET-Argumente immer in doppelte Anführungszeichen zu setzen, d. h.:

Setze „var1=füge hier deinen Wert ein“

Nun, obwohl das sinnlos war, TCC (und CMDebug) hatte keine Probleme beim Parsen des Befehls.

Gibt es Fälle, in denen Sie alles in doppelte Anführungszeichen setzen würden? Ja – zum Beispiel:

setze „var1=inserting>funny|characters&here“

Wenn Sie beispielsweise Befehlstrennzeichen oder Umleitungszeichen verwenden möchten, müssen Sie diese in Anführungszeichen setzen (oder maskieren), um zu verhindern, dass der Befehlsprozessor sie als Sonderzeichen interpretiert. Aber im Fall dieser Batchdatei gab es nie Sonderzeichen im Wert, die doppelte Anführungszeichen erforderten.

Also, wenn TCC Behandelt die doppelten Anführungszeichen. Was war das Problem? Der Entwickler hatte auch einige Aussagen, die so aussahen:

Legen Sie hier „var1=somevalue“ und mehr Text fest

TCC angenommen, dass „andmoretexthere“ an den Wert von var1 angehängt werden sollte. Was CMD.EXE jedoch tatsächlich tut, ist, alles nach dem schließenden doppelten Anführungszeichen zu ignorieren und die Zeile wie folgt umzuwandeln:

var1=irgendeinWert

Das kam für mich unerwartet (und nicht dokumentiert). Und wenn es weggeworfen werden sollte, warum hat der Autor der Batchdatei es dann eingefügt? Es geht nicht einmal darum, dass CMD nach passenden Angeboten sucht – zum Beispiel:

Legen Sie hier „var1=some“value“ und hier „more“ fest

Ergebnisse in:

var1=einiger „Wert“ hier und „mehr“.

Daher sucht CMD nach einem doppelten Anführungszeichen vor dem Variablennamen, und wenn es eines findet, sucht es nach dem *letzten* doppelten Anführungszeichen in der Zeile und verwirft alles, was darauf folgt. Warum? Wer weiß? Warum hat der Entwickler dieser Batchdatei diesen zusätzlichen Text nach dem letzten Zitat hinzugefügt? Ein Tippfehler? Übermäßige Insider-Klugheit?? Ich habe keine Ahnung.

Ich habe dazu einen Kludge hinzugefügt TCC, aber wenn Sie nicht die gesamte SET-Anweisung zitieren, werden Sie nie darauf stoßen.

Im nächsten Artikel werde ich über das andere Problem in dieser Batchdatei sprechen: eine merkwürdige Verwendung der CMD-Variablensubstitutionssyntax und den CMD-Fehler, den der Autor der Batchdatei auf überraschende (zumindest überraschende) Weise umgangen hat TCC!) Weg.