Fichiers de commandes Windows: .bat vs .cmd?

Question

Si je comprends bien, .bat correspond à l'ancienne convention de dénomination 16 bits et .cmd à Windows 32 bits, c'est-à-dire en 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 autre. En supposant que mon code ne doit jamais être exécuté sur une version antérieure à NT, la façon dont je nomme mes fichiers de traitement de lot importe-t-elle vraiment, ou existe-t-il un piège qui m'attend en utilisant le mauvais suffixe?

Answer 1

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

  

Les différences entre .CMD et .BAT en ce qui concerne CMD.EXE   sont: Avec les extensions activées, PATH / APPEND / PROMPT / SET / ASSOC dans .CMD   les fichiers définiront ERRORLEVEL indépendamment de l'erreur. .BAT définit ERRORLEVEL   seulement 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, le résultat obtenu sera le suivant:

• laissé seul à sa valeur non-0 dans un fichier .bat
• réinitialisé à 0 dans un fichier .cmd.

Answer 2

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:

1. command.com est 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.
2. cmd.exe est le processeur de commande 32 bits sous Windows NT (les systèmes d’exploitation Windows 64 bits ont également une version 64 bits). cmd n'a jamais fait partie de Windows 9x. Il provenait d'OS / 2 version 1.0 et la version OS / 2 de start a commencé 16 bits (mais était néanmoins un programme en mode protégé à part entière avec des commandes telles que ComSpec). Windows NT a hérité .bat d’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, son .cmd programme est resté à 16 bits OS / 2 1.x.
3. La variable ^ env définit quel programme est lancé par les scripts \ & | > < ^ et PUSHD. (À partir de WinNT, la valeur par défaut est POPD.)
4. SET /A i+=1 est rétrocompatible avec SET %varname:expression%.
5. Un script conçu pour FOR /F peut être nommé CALL :label pour empêcher toute exécution accidentelle sous Windows 9x. Cette extension de nom de fichier remonte également à OS / 2 versions 1.0 et 1987.

Voici une liste des <=> fonctionnalités non prises en charge par <=>:

• Noms de fichiers longs (dépassant le format 8.3)
• Historique des commandes
• achèvement de l'onglet
• Caractère d'échappement: <=> (utiliser pour: <=>)
• Pile de répertoires: <=> / <=>
• Calcul arithmétique entier: <=>
• Rechercher / Remplacer / Sous-chaîne: <=>
• Substitution de commande: <=> (existait auparavant, a été améliorée)
• Fonctions: <=>

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 exécuter, 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:

• cmd.exe
• command.com

wikipedia: Comparaison des interpréteurs de commande

Answer 3

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 par inadvertance sur des systèmes non NT.
• <=> permet aux commandes intégrées de remplacer Errorlevel par 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.

Answer 4

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.

Autres informations intéressantes sur command.com vs 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 assez subtile   fonctionnalité de Windows NT qui est très   important. 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 cette coquille, il ne fait pas   effectivement l'exécuter. Au lieu de cela, il   emballe le texte de la commande et l'envoie   à un shell de commande CMD.EXE 32 bits pour   exécution. Parce que toutes les commandes sont   effectivement exécuté par CMD.EXE (le   Shell de commande Windows NT), le format 16 bits   shell hérite de toutes les fonctionnalités et   installations de l'intégralité de Windows NT   shell.

Answer 5

RE: Apparemment, lorsque command.com est appelé, c'est un mystère complexe;

Il y a plusieurs mois, au cours d'un projet, nous devions comprendre pourquoi certains programmes que nous voulions exécuter sous CMD.EXE étaient en fait exécutés sous COMMAND.COM. Le & Quot; programme & Quot; en question était un très vieux fichier .BAT, qui fonctionne encore tous les jours.

Nous avons découvert que le fichier de traitement par lots s’exécutait sous COMMAND.COM parce qu’il était démarré à partir d’un fichier .PIF (également ancien). Les paramètres de configuration de la mémoire spéciaux disponibles uniquement via un fichier PIF étant devenus inutiles, nous les avons remplacés par un raccourci clavier traditionnel.

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.

Answer 6

Étant donné que l'article d'origine traitait des conséquences de l'utilisation du suffixe .bat ou .cmd , il n'est pas nécessaire que les commandes à l'intérieur du 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:

• entrez nom de fichier ou nom de fichier .bat sur la ligne de commande pour exécuter le fichier .bat

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

Answer 7

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>

Answer 8

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 visible sur les fichiers courts) et stable en tant que bat exécuté dans un environnement 16 bits émulé NTVDM

Answer 9

Je crois que si vous modifiez la valeur de la variable d'environnement ComSpec en% SystemRoot% system32 \ cmd.exe, peu importe si l'extension du fichier est .BAT ou .CMD. Je ne suis pas sûr, mais cela peut même être la valeur par défaut pour WinXP et versions ultérieures.

Answer 10

Légèrement hors sujet, mais avez-vous envisagé de hébergeur de script Windows ? Vous trouverez peut-être plus agréable.

Answer 11

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

Answer 12

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

Answer 13

Voici une différence que j'ai découverte: EnableDelayedExpansion est obligatoire dans .cmd fichiers.
Comme dans le cas des .bat fichiers, il est implicite par défaut. ( Windows 10 )

dir *? | find /i "FOOBAR"
if ERRORLEVEL 0             (
set result="found"  ) else  (
set result="not found"  )
echo %result%

Ceci fonctionne dans found mais est toujours line 2 dans le cas d'un fichier <=>.
Si vous modifiez <=> comme suit, cela fonctionne comme prévu:

if %ERRORLEVEL% equ 0       (

Et enfin pour le <=> fichier, cela fonctionne correctement:

setLocal EnableDelayedExpansion
...
if !ErrorLevel! equ 1       (
...

Answer 14

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 le modifiez avant la fin de son exécution. Cela va gâcher les fichiers bat, mais pas les fichiers cmd.