Fichiers batch Windows: .bat vs .cmd?

Si je comprends bien, .batc'est l'ancienne convention de dénomination 16 bits, et .cmdc'est pour Windows 32 bits, c'est-à-dire en commençant par NT. Mais je continue de voir des fichiers .bat partout, et ils semblent fonctionner exactement de la même manière en utilisant l'un ou l'autre suffixe. En supposant que mon code ne sera jamais besoin sur quoi que ce soit de plus que NT, est - ce vraiment de quelle manière je nomme mes fichiers batch, ou est - il un Gotcha me attend en utilisant le mauvais suffixe?

De cette publication de groupe de nouvelles par Mark Zbikowski lui-même:

Les différences entre .CMD et .BAT en ce qui concerne CMD.EXE sont les suivantes: Avec les extensions activées, PATH / APPEND / PROMPT / SET / ASSOC dans les fichiers .CMD définira ERRORLEVEL indépendamment de l'erreur. .BAT définit ERRORLEVEL uniquement sur les erreurs.

En d'autres termes, si ERRORLEVEL est défini sur non-0 et que vous exécutez ensuite l'une de ces commandes, le résultat ERRORLEVEL sera:

• laissé seul à sa valeur différente de 0 dans un fichier .bat
• réinitialisé à 0 dans un fichier .cmd.

Voici une compilation d'informations vérifiées à partir des différentes réponses et références citées dans ce fil:

1. command.com est le processeur de commandes 16 bits introduit dans MS-DOS et a également été utilisé dans la série de systèmes d'exploitation Win9x.
2. cmd.exeest le processeur de commandes 32 bits de Windows NT (les systèmes d'exploitation Windows 64 bits ont également une version 64 bits). cmd.exen'a jamais fait partie de Windows 9x. Il est originaire de OS / 2 version 1.0, et la version OS / 2 de cmd16 bits a commencé (mais était néanmoins un programme en mode protégé à part entière avec des commandes comme start). Windows NT a hérité cmdd'OS / 2, mais la version Win32 de Windows NT a démarré en 32 bits. Bien que OS / 2 soit passé à 32 bits en 1992, il cmdrestait un programme OS / 2 1.x 16 bits.
3. La ComSpecvariable env définit le programme lancé .batet les .cmdscripts. (À partir de WinNT, cette valeur par défaut est cmd.exe.)
4. cmd.exeest rétrocompatible avec command.com.
5. Un script conçu pour cmd.exepeut être nommé .cmdpour empêcher une exécution accidentelle sur Windows 9x. Cette extension de nom de fichier remonte également à OS / 2 version 1.0 et 1987.

Voici une liste de cmd.exefonctionnalités qui ne sont pas prises en charge par command.com:

• Noms de fichiers longs (dépassant le format 8.3)
• Historique des commandes
• Compléter la tabulation
• Caractère d' échappement: ^(utilisation pour: \ & | > < ^)
• Pile de répertoires: PUSHD/POPD
• Arithmétique entière: SET /A i+=1
• Rechercher / remplacer / sous-chaîne: SET %varname:expression%
• Substitution de commandes: FOR /F(existait auparavant, a été améliorée)
• Les fonctions: CALL :label

Ordre d'exécution:

Si les versions .bat et .cmd d'un script (test.bat, test.cmd) se trouvent dans le même dossier et que vous exécutez le script sans l'extension (test), par défaut, la version .bat du script s'exécutera, même sur Windows 64 bits 7. L'ordre d'exécution est contrôlé par la variable d'environnement PATHEXT. Voir Ordre dans lequel l'invite de commandes exécute les fichiers pour plus de détails.

Références:

• cmd.exe
• command.com

wikipedia: Comparaison des shells de commande

Ces réponses sont un peu trop longues et axées sur une utilisation interactive. Les différences importantes pour les scripts sont les suivantes:

• .cmd empêche l'exécution accidentelle sur des systèmes non NT.
• .cmd permet aux commandes intégrées de changer Errorlevel à 0 en cas de succès.

Pas si excitant, hein?

Auparavant, un certain nombre de fonctionnalités supplémentaires étaient activées dans les .cmdfichiers, appelées extensions de commandes. Cependant, ils sont désormais activés par défaut pour les fichiers .batet .cmdsous Windows 2000 et versions ultérieures.

Conclusion: en 2012 et au-delà, je recommande d'utiliser .cmdexclusivement.

Non, cela n'a aucune importance. Sous NT, l'extension .bat et .cmd entraînent toutes deux le traitement par le processeur cmd.exe du fichier de la même manière.

Informations supplémentaires intéressantes sur command.com par rapport à cmd.exe sur les systèmes de classe WinNT de MS TechNet ( http://technet.microsoft.com/en-us/library/cc723564.aspx ):

Ce comportement révèle une fonctionnalité assez subtile de Windows NT qui est très importante. Le shell MS-DOS 16 bits (COMMAND.COM) fourni avec Windows NT est spécialement conçu pour Windows NT. Lorsqu'une commande est entrée pour être exécutée par ce shell, elle ne l'exécute pas réellement. Au lieu de cela, il conditionne le texte de la commande et l'envoie à un shell de commande CMD.EXE 32 bits pour exécution. Étant donné que toutes les commandes sont réellement exécutées par CMD.EXE (le shell de commandes Windows NT), le shell 16 bits hérite de toutes les fonctionnalités et fonctionnalités du shell Windows NT complet.

RE: Apparemment, quand command.com est invoqué, c'est un peu un mystère complexe;

Il y a plusieurs mois, au cours d'un projet, nous avons dû comprendre pourquoi certains programmes que nous voulions exécuter sous CMD.EXE fonctionnaient en fait sous COMMAND.COM. Le "programme" en question était un très ancien fichier .BAT, qui fonctionne toujours quotidiennement.

Nous avons découvert que la raison pour laquelle le fichier de commandes s'exécutait sous COMMAND.COM est qu'il était démarré à partir d'un fichier .PIF (également ancien). Étant donné que les paramètres de configuration de mémoire spéciaux disponibles uniquement via un PIF ne sont plus pertinents, nous l'avons remplacé par un raccourci de bureau classique.

Le même fichier de commandes, lancé à partir du raccourci, s'exécute dans CMD.EXE. Quand on y pense, cela a du sens. La raison pour laquelle il nous a fallu si longtemps pour le comprendre était en partie due au fait que nous avions oublié que son article dans le groupe de démarrage était un PIF, car il était en production depuis 1998.

Néanmoins, sur Windows 7, les fichiers BAT ont également cette différence: si vous créez des fichiers TEST.BAT et TEST.CMD dans le même répertoire et que vous exécutez TEST dans ce répertoire, il exécutera le fichier BAT.

C:\>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

C:\Temp>echo echo bat > test.bat

C:\Temp>echo echo cmd > test.cmd

C:\Temp>test

C:\Temp>echo bat
bat

C:\Temp>

Étant donné que le message d'origine concernait les conséquences de l'utilisation du suffixe .bat ou .cmd , pas nécessairement les commandes à l' intérieur du fichier ...

Une autre différence entre .bat et .cmd est que si deux fichiers existent avec le même nom de fichier et ces deux extensions, alors:

• la saisie du nom de fichier ou du nom de fichier .bat sur la ligne de commande exécutera le fichier .bat

• pour exécuter le fichier .cmd, vous devez entrer le nom de fichier .cmd

tout ce qui fonctionne dans un lot devrait fonctionner dans un cmd; cmd fournit quelques extensions pour contrôler l'environnement. également, cmd est exécuté par dans le nouvel interpréteur cmd et devrait donc être plus rapide (non visible sur les fichiers courts) et plus stable lorsque la chauve-souris s'exécute sous l'environnement 16 bits émulé NTVDM

L'exécution des fichiers .cmd et .bat est différente car dans une variable de niveau d'erreur .cmd, elle peut changer sur une commande qui est affectée par les extensions de commande. C'est à peu près tout.

Je crois que si vous changez la valeur de la variable d'environnement ComSpec en %SystemRoot%system32\cmd.exe(CMD), alors peu importe si l'extension de fichier est .BATou .CMD. Je ne suis pas sûr, mais cela peut même être la valeur par défaut pour WinXP et supérieur.

Légèrement hors sujet, mais avez-vous envisagé Windows Scripting Host ? Vous pourriez trouver cela plus agréable.

L'extension ne fait aucune différence.

Il existe de légères différences entre la COMMAND.COMgestion du fichier et CMD.EXE.

une différence:

Les fichiers .cmd sont chargés en mémoire avant d'être exécutés. Les fichiers .bat exécutent une ligne, lisent la ligne suivante, exécutent cette ligne ...

vous pouvez le rencontrer lorsque vous exécutez un fichier de script, puis l'éditez avant qu'il ne soit terminé. les fichiers bat seront gâchés par cela, mais pas les fichiers cmd.