Windows-Batch-Dateien: .bat vs. .cmd?

Question

So wie ich es verstehe, .bat ist die alte 16-Bit-Benennungskonvention, und .cmd ist für 32-Bit-Windows, d. h. ab NT. Aber ich sehe weiterhin überall .bat-Dateien, und sie scheinen mit beiden Suffixen genau gleich zu funktionieren. Wenn ich davon ausgehe, dass mein Code nie auf etwas Älterem als NT laufen muss, spielt es dann wirklich eine Rolle, wie ich meine Batch-Dateien benenne, oder gibt es eine Ich hab's kapiert erwarten, dass ich das falsche Suffix verwende?

Answer 1

De diese Meldung der Nachrichtengruppe で Mark Zbikowski selbst:

Die Unterschiede zwischen .CMD und .BAT, soweit CMD.EXE betroffen ist sind: Wenn die Erweiterungen aktiviert sind, setzt PATH/APPEND/PROMPT/SET/ASSOC in .CMD Dateien ERRORLEVEL gesetzt, unabhängig vom Fehler. .BAT setzt ERRORLEVEL nur bei Fehlern.

Mit anderen Worten: Wenn ERRORLEVEL auf einen Wert ungleich 0 gesetzt ist und Sie dann einen dieser Befehle ausführen, wird der resultierende ERRORLEVEL sein:

• in einer .bat-Datei nicht auf den Wert 0 gesetzt wird
• in einer .cmd-Datei auf 0 zurückgesetzt werden.

Answer 2

Hier ist eine Zusammenstellung verifizierter Informationen aus den verschiedenen Antworten und zitierten Referenzen in diesem Thread:

0. command.com ist der 16-Bit-Befehlsprozessor, der mit MS-DOS eingeführt und auch in der Win9x-Betriebssystemreihe verwendet wurde.
1. cmd.exe ist der 32-Bit-Befehlsprozessor in Windows NT (für 64-Bit-Windows-Betriebssysteme gibt es auch eine 64-Bit-Version). cmd.exe war nie Teil von Windows 9x. Es stammt ursprünglich aus OS/2 Version 1.0, und die OS/2-Version von cmd begann mit 16-Bit (war aber dennoch ein vollwertiges Programm im geschützten Modus mit Befehlen wie start ). Windows NT hat geerbt cmd von OS/2, aber die Win32-Version von Windows NT begann mit 32-Bit. Obwohl OS/2 1992 auf 32-Bit umgestellt wurde, ist seine cmd blieb ein 16-Bit-OS/2-1.x-Programm.
2. El ComSpec env-Variable definiert, welches Programm von .bat y .cmd Skripte. (Ab WinNT ist dies standardmäßig der Wert cmd.exe .)
3. cmd.exe ist rückwärtskompatibel mit command.com .
4. Ein Skript, das für folgende Zwecke bestimmt ist cmd.exe können genannt werden .cmd um eine versehentliche Ausführung unter Windows 9x zu verhindern. Diese Dateinamenerweiterung stammt ebenfalls aus OS/2 Version 1.0 und 1987.

Hier ist eine Liste von cmd.exe Funktionen, die nicht unterstützt werden von command.com :

• Lange Dateinamen (die das 8.3-Format überschreiten)
• Befehlsverlauf
• Registerkarte Fertigstellung
• Escape-Zeichen: ^ (Verwendung für: \ & | > < ^ )
• Verzeichnisstapel: PUSHD / POPD
• Ganzzahlige Arithmetik: SET /A i+=1
• Suchen/Ersetzen/Substring: SET %varname:expression%
• Befehlsersetzung: FOR /F (existierte bereits, wurde verbessert)
• Funktionen: CALL :label

Reihenfolge der Vollstreckung:

Wenn sich sowohl die .bat- als auch die .cmd-Version eines Skripts (test.bat, test.cmd) im selben Ordner befinden und Sie das Skript ohne die Erweiterung (test) ausführen, wird standardmäßig die .bat-Version des Skripts ausgeführt, auch unter 64-Bit-Windows 7. Die Reihenfolge der Ausführung wird durch die Umgebungsvariable PATHEXT gesteuert. Siehe Reihenfolge, in der die Eingabeaufforderung Dateien ausführt für weitere Einzelheiten.

Referenzen:

• cmd.exe
• command.com

wikipedia: Vergleich der Befehlsshells

Answer 3

Diese Antworten sind ein wenig zu lang und konzentrieren sich auf die interaktive Nutzung. Die wichtigsten Unterschiede für die Skripterstellung sind:

• .cmd verhindert die versehentliche Ausführung auf Nicht-NT-Systemen.
• .cmd ermöglicht es eingebauten Befehlen, Errorlevel bei Erfolg auf 0 zu ändern.

Nicht so aufregend, oder?

Früher gab es eine Reihe von zusätzlichen Funktionen, die in .cmd Dateien, die so genannten Befehlserweiterungen. Allerdings sind sie jetzt standardmäßig für beide aktiviert .bat y .cmd Dateien unter Windows 2000 und höher.

Unterm Strich: im Jahr 2012 und darüber hinaus, empfehle ich die Verwendung von .cmd ausschließlich.

Answer 4

Nein - das spielt überhaupt keine Rolle. Unter NT führen die Erweiterungen .bat und .cmd dazu, dass der cmd.exe-Prozessor die Datei auf genau dieselbe Weise verarbeitet.

Weitere interessante Informationen über command.com vs. cmd.exe auf Systemen der WinNT-Klasse von MS TechNet ( http://technet.microsoft.com/en-us/library/cc723564.aspx ):

Dieses Verhalten offenbart eine recht subtile Funktion von Windows NT, die sehr wichtig ist wichtig ist. Die 16-Bit MS-DOS-Shell (COMMAND.COM), die mit Windows NT mitgeliefert wird, wurde speziell für Windows NT ENTWICKELT. Wenn ein Befehl zur Ausführung durch diese Shell eingegeben wird, wird er tatsächlich ausgeführt. Stattdessen wird den Befehlstext zusammen und sendet ihn an eine 32-Bit-Befehlsshell CMD.EXE zur Ausführung. Da alle Befehle tatsächlich von CMD.EXE (der Windows NT-Befehlsshell) ausgeführt werden, erbt die 16-Bit Shell alle Funktionen und Möglichkeiten der vollständigen Windows NT Shell.

Answer 5

RE: Wann command.com aufgerufen wird, ist anscheinend ein komplexes Rätsel;

Vor einigen Monaten mussten wir im Rahmen eines Projekts herausfinden, warum einige Programme, die wir unter CMD.EXE ausführen wollten, in Wirklichkeit unter COMMAND.COM liefen. Bei dem fraglichen "Programm" handelte es sich um eine sehr alte .BAT-Datei, die immer noch täglich ausgeführt wird.

Wir fanden heraus, dass die Batch-Datei unter COMMAND.COM lief, weil sie von einer (ebenfalls uralten) .PIF-Datei gestartet wurde. Da die speziellen Speicherkonfigurationseinstellungen, die nur über eine PIF-Datei verfügbar sind, irrelevant geworden sind, haben wir sie durch eine herkömmliche Desktop-Verknüpfung ersetzt.

Dieselbe Stapeldatei, die über die Verknüpfung aufgerufen wird, wird in CMD.EXE ausgeführt. Wenn man darüber nachdenkt, ergibt das einen Sinn. Dass wir so lange gebraucht haben, um das herauszufinden, lag zum Teil daran, dass wir vergessen hatten, dass es sich bei dem Eintrag in der Autostart-Gruppe um eine PIF handelte, da sie bereits seit 1998 in Produktion war.