Fichiers de commandes Windows: .bat vs .cmd?
Si je comprends bien, .bat est l’ancienne convention de dénomination 16 bits et .cmd est destiné à Windows 32 bits, c’est-à-dire commençant par NT. Mais je continue à voir des fichiers .bat partout, et ils semblent fonctionner exactement de la même manière, qu’ils utilisent un suffixe ou un suffixe. En supposant que mon code n’aura jamais besoin d’être exécuté sur une version antérieure à NT, est-ce que la façon dont je nomme mes fichiers batch est importante, ou y at-il des gotcha qui m’attendent en utilisant le mauvais suffixe?
De cette publication dans un groupe de discussion 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 une valeur autre que 0 et que vous exécutez l'une de ces commandes, ERRORLEVEL sera le suivant:
- laissé seul à sa valeur non-0 dans un fichier .bat
- réinitialiser à 0 dans un fichier .cmd.
Voici une compilation d'informations vérifiées provenant des différentes réponses et références citées dans ce fil de discussion:
command.comest le processeur de commande 16 bits introduit dans MS-DOS et a également été utilisé dans la série de systèmes d'exploitation Win9x.cmd.exeest le processeur de commande 32 bits sous 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 provenait d'OS/2 version 1.0 et la version OS/2 decmda commencé 16 bits (mais était néanmoins un programme en mode protégé à part entière avec des commandes telles questartname__). Windows NT a hérité decmdde OS/2, mais la version Win32 de Windows NT a démarré en 32 bits. Bien que OS/2 soit passé en 32 bits en 1992, soncmdrestait un programme OS/2 1.x 16 bits.- La variable env
ComSpecdéfinit le programme lancé par les scripts.batet.cmd. (À partir de WinNT, la valeur par défaut estcmd.exe.) cmd.exeest rétrocompatible aveccommand.com.- Un script conçu pour
cmd.exepeut être nommé.cmdpour empêcher toute exécution accidentelle sous Windows 9x. Cette extension de nom de fichier remonte également à OS/2 version 1.0 et 1987.
Voici une liste des fonctionnalités de cmd.exe qui ne sont pas prises en charge par command.com:
- Noms de fichiers longs (dépassant le format 8.3)
- Historique de commande
- Complétion par onglet
- Caractère d'échappement:
^(utilisé pour:\ & | > < ^) - Pile de répertoires:
PUSHDname __/POPDname__ - Calcul arithmétique entier:
SET /A i+=1 - Rechercher/Remplacer/Sous-chaîne:
SET %varname:expression% - Substitution de commande:
FOR /F(existait auparavant, a été amélioré) - 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), la version .bat du script est exécutée par défaut, même sous Windows 7 64 bits. L'ordre d'exécution est contrôlé par la variable d'environnement PATHEXT. Voir Ordre dans lequel l'invite de commande exécute les fichiers pour plus de détails.
Références:
wikipedia: Comparaison des obus 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:
.cmdempêche l'exécution par inadvertance sur des systèmes non-NT..cmdpermet aux commandes intégrées de changer Errorlevel à 0 en cas de succès.
Les extensions de commande sont activées par défaut dans les fichiers .bat et .cmd sous Windows 2000 ou version ultérieure.
En 2012 et au-delà, je recommande d'utiliser exclusivement .cmd.
Non, peu importe. Sous NT, les extensions .bat et .cmd font que le processeur cmd.exe traite le fichier exactement de la même manière.
Informations intéressantes supplémentaires sur command.com et cmd.exe sur les systèmes de classe WinNT à partir de MS TechNet ( http://technet.Microsoft.com/en-us/library/cc723564.aspx ):
Ce comportement révèle une fonctionnalité très 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 exécution par ce shell, elle ne l'exécute pas réellement. Au lieu de cela, il empaquette le texte de la commande et l'envoie à un shell CMD.EXE 32 bits pour exécution. Parce que toutes les commandes sont réellement exécutées par CMD.EXE (le shell de commande Windows NT), le shell 16 bits hérite de toutes les fonctionnalités et installations du shell Windows NT complet.
RE: Apparemment, lorsque command.com est appelé, c'est 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 étaient en fait exécutés sous COMMAND.COM. Le "programme" en question était un très ancien fichier .BAT, qui s'exécute toujours quotidiennement.
Nous avons découvert que la raison pour laquelle le fichier de traitement par lots 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 fichier PIF sont devenus inutiles, nous les avons remplacés par un raccourci de bureau classique.
Le même fichier de commandes, lancé à partir du raccourci, s'exécute dans CMD.EXE. Quand vous y réfléchissez, cela a du sens. La raison pour laquelle il nous a fallu si longtemps pour le comprendre est en partie due au fait que nous avions oublié que son article dans le groupe de startups était un PIF, car il était en production depuis 1998.
Puisque le message original concernait les conséquences de l’utilisation du .bat ou .cmd suffixe, pas nécessairement les commandes à l’intérieur le fichier ...
Une autre différence entre .bat et .cmd réside dans le fait que s'il existe deux fichiers portant le même nom et les deux extensions, alors:
entrer nom du fichier ou nom du fichier. bat sur la ligne de commande exécute le fichier .bat
pour exécuter le fichier .cmd, vous devez entrer nom du fichier. cmd
Néanmoins, sous 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, le fichier BAT sera exécuté.
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>
tout ce qui fonctionne dans un lot devrait fonctionner dans un cmd; cmd fournit des extensions pour contrôler l'environnement. de plus, cmd est exécuté par le nouvel interpréteur cmd et devrait donc être plus rapide (non perceptible sur les fichiers courts) et stable, car bat s'exécute dans l'environnement 16 bits émulé par NTVDM.
Légèrement hors sujet, mais avez-vous pensé à Windows Scripting Host ? Vous pourriez le trouver plus agréable.
Je crois que si vous modifiez la valeur de la variable d’environnement ComSpec sur% SystemRoot% system32\cmd.exe, l’importation du fichier .BAT ou .CMD n’a aucune importance. Je ne suis pas sûr, mais cela peut même être la valeur par défaut pour WinXP et les versions ultérieures.
L'exécution des fichiers .cmd et .bat est différente car, dans une variable de niveau d'erreur .cmd, elle peut être modifiée pour une commande affectée par des extensions de commande. C'est à peu près tout.
L'extension ne fait aucune différence. Il existe de légères différences entre COMMAND.COM gérant le fichier et CMD.EXE.