Archivos por lotes de Windows: .bat vs .cmd?

Según tengo entendido, .bates la antigua convención de nomenclatura de 16 bits, y .cmdes para Windows de 32 bits, es decir, comenzando con NT. Pero sigo viendo archivos .bat en todas partes, y parecen funcionar exactamente igual usando cualquier sufijo. Suponiendo que nunca tendrá mi código para funcionar en cualquier cosa mayor que NT, es lo que realmente importa en qué dirección nombrar mis archivos por lotes, o hay alguna Gotcha me espera utilizando el sufijo mal?

De este grupo de noticias publicado por el propio Mark Zbikowski :

Las diferencias entre .CMD y .BAT en lo que respecta a CMD.EXE son: Con las extensiones habilitadas, PATH / APPEND / PROMPT / SET / ASSOC en archivos .CMD establecerá ERRORLEVEL independientemente del error. .BAT establece ERRORLEVEL solo en errores.

En otras palabras, si ERRORLEVEL está configurado en un valor distinto de 0 y luego ejecuta uno de esos comandos, el ERRORLEVEL resultante será:

• dejado solo en su valor no 0 en un archivo .bat
• restablecer a 0 en un archivo .cmd.

Aquí hay una compilación de información verificada de las diversas respuestas y referencias citadas en este hilo:

1. command.com es el procesador de comandos de 16 bits introducido en MS-DOS y también se utilizó en la serie Win9x de sistemas operativos.
2. cmd.exees el procesador de comandos de 32 bits en Windows NT (los sistemas operativos Windows de 64 bits también tienen una versión de 64 bits). cmd.exenunca fue parte de Windows 9x. Se originó en OS / 2 versión 1.0, y la versión OS / 2 de cmd16 bits comenzó (pero no obstante fue un programa de modo protegido completo con comandos como start). Windows NT heredó cmdde OS / 2, pero la versión Win32 de Windows NT comenzó con 32 bits. Aunque OS / 2 pasó a 32 bits en 1992, cmdsiguió siendo un programa OS / 2 1.x de 16 bits.
3. La ComSpecvariable env define qué programa es lanzado por .baty .cmdscripts. (Comenzando con WinNT, este valor predeterminado es cmd.exe).
4. cmd.exees compatible con versiones anteriores command.com.
5. Se cmd.exepuede nombrar un script diseñado para .cmdevitar la ejecución accidental en Windows 9x. Esta extensión de nombre de archivo también se remonta a OS / 2 versión 1.0 y 1987.

Aquí hay una lista de cmd.execaracterísticas que no son compatibles con command.com:

• Nombres de archivo largos (que exceden el formato 8.3)
• Historial de comandos
• Pestaña completada
• Carácter de escape: ^(Uso para: \ & | > < ^)
• Pila de directorio: PUSHD/POPD
• Aritmética de enteros: SET /A i+=1
• Buscar / Reemplazar / Subcadena: SET %varname:expression%
• Sustitución de comandos: FOR /F(existía antes, se ha mejorado)
• Funciones: CALL :label

Orden de Ejecución:

Si las versiones .bat y .cmd de un script (test.bat, test.cmd) están en la misma carpeta y ejecuta el script sin la extensión (prueba), de forma predeterminada se ejecutará la versión .bat del script, incluso en Windows 7 de 64 bits. El orden de ejecución está controlado por la variable de entorno PATHEXT. Consulte el orden en que el símbolo del sistema ejecuta los archivos para obtener más detalles.

Referencias

• cmd.exe
• command.com

wikipedia: Comparación de shells de comando

Estas respuestas son demasiado largas y se centran en el uso interactivo. Las diferencias importantes para las secuencias de comandos son:

• .cmd evita la ejecución involuntaria en sistemas que no son NT.
• .cmd permite que los comandos integrados cambien Errorlevel a 0 en caso de éxito.

No es tan emocionante, ¿eh?

Solía ​​haber una serie de características adicionales habilitadas en los .cmdarchivos, llamadas Extensiones de comando. Sin embargo, ahora están activadas por defecto para ambos .baty .cmdarchivos en Windows 2000 y versiones posteriores.

En pocas palabras: en 2012 y más allá, recomiendo usar .cmdexclusivamente.

No, no importa en lo más mínimo. En NT, las extensiones .bat y .cmd hacen que el procesador cmd.exe procese el archivo exactamente de la misma manera.

Información interesante adicional sobre command.com vs.cmd.exe en sistemas de clase WinNT de MS TechNet ( http://technet.microsoft.com/en-us/library/cc723564.aspx ):

Este comportamiento revela una característica bastante sutil de Windows NT que es muy importante. El shell de MS-DOS de 16 bits (COMMAND.COM) que se incluye con Windows NT está especialmente diseñado para Windows NT. Cuando un shell ingresa un comando para su ejecución, en realidad no lo ejecuta. En su lugar, empaqueta el texto del comando y lo envía a un shell de comando CMD.EXE de 32 bits para su ejecución. Debido a que CMD.EXE (el shell de comandos de Windows NT) ejecuta todos los comandos, el shell de 16 bits hereda todas las características e instalaciones del shell completo de Windows NT.

RE: Aparentemente cuando se invoca command.com es un misterio un poco complejo;

Hace varios meses, durante el curso de un proyecto, tuvimos que descubrir por qué algunos programas que queríamos ejecutar bajo CMD.EXE, de hecho, se ejecutaban bajo COMMAND.COM. El "programa" en cuestión era un archivo .BAT muy antiguo, que todavía se ejecuta a diario.

Descubrimos que la razón por la que el archivo por lotes se ejecutó bajo COMMAND.COM es porque se estaba iniciando desde un archivo .PIF (también antiguo). Dado que los ajustes de configuración de memoria especiales disponibles solo a través de un PIF se han vuelto irrelevantes, lo reemplazamos con un acceso directo de escritorio convencional.

El mismo archivo por lotes, lanzado desde el acceso directo, se ejecuta en CMD.EXE. Cuando lo piensas, esto tiene sentido. La razón por la que nos tomó tanto tiempo descubrirlo se debió en parte al hecho de que habíamos olvidado que su elemento en el grupo de inicio era un PIF, porque había estado en producción desde 1998.

Aún así, en Windows 7, los archivos BAT también tienen esta diferencia: si alguna vez crea archivos TEST.BAT y TEST.CMD en el mismo directorio, y ejecuta TEST en ese directorio, ejecutará el archivo 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>

Dado que la publicación original se refería a las consecuencias del uso del sufijo .bat o .cmd , no necesariamente los comandos dentro del archivo ...

Otra diferencia entre .bat y .cmd es que si existen dos archivos con el mismo nombre de archivo y ambas extensiones, entonces:

• ingresar el nombre del archivo o el nombre del archivo .bat en la línea de comando ejecutará el archivo .bat

• para ejecutar el archivo .cmd, debe ingresar el nombre de archivo .cmd

todo lo que funciona en un lote debería funcionar en un cmd; cmd proporciona algunas extensiones para controlar el entorno. Además, cmd se ejecuta en un nuevo intérprete de cmd y, por lo tanto, debería ser más rápido (no se nota en archivos cortos) y más estable a medida que bat se ejecuta en el entorno de 16 bits emulado NTVDM

La ejecución de archivos .cmd y .bat es diferente porque en una variable de nivel de error .cmd puede cambiar en un comando que se ve afectado por las extensiones de comando. Eso es todo realmente.

Creo que si cambia el valor de la variable de entorno ComSpec a %SystemRoot%system32\cmd.exe(CMD), no importa si la extensión del archivo es .BATo .CMD. No estoy seguro, pero esto incluso puede ser el predeterminado para WinXP y superior.

Ligeramente fuera de tema, pero ¿ha considerado Windows Scripting Host ? Puede que te resulte más agradable.

La extensión no hace ninguna diferencia.

Existen ligeras diferencias entre COMMAND.COMel manejo del archivo vs CMD.EXE.

una diferencia:

Los archivos .cmd se cargan en la memoria antes de ejecutarse. Los archivos .bat ejecutan una línea, leen la siguiente línea, ejecutan esa línea ...

puede encontrar esto cuando ejecuta un archivo de script y luego lo edita antes de que termine de ejecutarse. Esto dañará los archivos bat, pero los archivos cmd no.