Según tengo entendido, .bat es la antigua convención de nombres de 16 bits, y .cmd es para Windows de 32 bits, es decir, a partir de NT. Pero sigo viendo archivos .bat por todas partes, y parecen funcionar exactamente igual usando cualquiera de los dos sufijos. Asumiendo que mi código nunca necesitará ejecutarse en algo más antiguo que NT, ¿realmente importa cómo nombre mis archivos batch, o hay algún Gotcha ¿me espera usando el sufijo incorrecto?
Respuestas
¿Demasiados anuncios?
Chris Noe
Puntos
8375
Aquí hay una recopilación de información verificada a partir de las diferentes respuestas y referencias citadas en este hilo:
-
command.com16-bit procesador de comandos introducidos en MS-DOS y también fue utilizado en la Win9x serie de sistemas operativos. -
cmd.exees de 32-bit procesador de comandos de Windows NT (Windows de 64 bits de sistemas operativos 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 de OS/2 decmdcomenzó de 16 bit (pero que sin embargo fue un completo modo protegido programa con los comandos comostart). Windows NT heredadocmdde OS/2, Windows NT versión Win32 comenzó de 32 bits. Aunque OS/2 fue de 32 bits en 1992, sucmdpermaneció 16-bit OS/2 1.x programa. - La
ComSpecenv variable define el programa es ejecutado por.baty.cmdde secuencias de comandos. (A partir de WinNT el valor predeterminado escmd.exe.) -
cmd.exees compatible concommand.com. - Una secuencia de comandos que está diseñado para
cmd.exepuede ser nombrado.cmda prevenir accidentes en ejecución en Windows 9x. Esta extensión de nombre de archivo que data de OS/2 versión 1.0 y 1987.
Aquí está una lista de cmd.exe características que no son compatibles con command.com:
- Los nombres de archivo largos (mayor que el formato 8.3)
- Historial de comandos
- Ficha de finalización
- Carácter de Escape:
^(Uso para:\ & | > < ^) - Directorio de pila:
PUSHD/POPD - Aritmética de enteros:
SET /A i+=1 - Buscar/Reemplazar/Subcadena:
SET %varname:expression% - La sustitución de comandos:
FOR /F(existido antes, que ha sido mejorada) - Funciones:
CALL :label
Orden de Ejecución:
Si ambos .bat y .cmd versiones de una secuencia de comandos (test.bat, test.cmd) están en la misma carpeta y ejecutar el script sin la extensión (de prueba), por defecto el .bat versión de la secuencia de comandos se ejecute, incluso en la versión de 64 bits de Windows 7. El orden de ejecución es controlada por la variable de entorno PATHEXT. Ver Orden en el que Símbolo del sistema ejecuta archivos para obtener más detalles.
Referencias:
wikipedia: Comparación de los shells de comandos
De La Wikipedia:
Nueva Cita de Wikipedia
La única diferencia conocida entre .cmd y archivo .bat ejecución es que en un Archivo .cmd la variable ERRORLEVEL los cambios, incluso en un comando de éxito que se ve afectado por las Extensiones de Comando (cuando las Extensiones de Comando están habilitadas) mientras que en los archivos .bat el ERRORLEVEL los cambios de variables sólo sobre los errores.
El origen de la Wikipedia cita anterior se basa en realidad en este grupo de noticias de la publicación.
Las diferencias entre .CMD y .BAT tan lejos como CMD.EXE es cuestión son: Con las extensiones habilitadas, PATHde acceso/APPEND/PROMPT/SET/ASSOC en .CMD los archivos se establezca ERRORLEVEL independientemente de error. .BAT conjuntos de ERRORLEVEL sólo en los errores.
No sólo es un poco más restrictivo en cuanto a las diferencias, de la Wikipedia de texto, pero también es digno de ser mencionado explícitamente, dado el hecho de que fue publicado por la Marca Zbikowski a sí mismo - que le da una gran credibilidad bono en mi humilde opinión.
bendecko
Puntos
174
He encontrado un "gotcha". Siempre me parecieron intercambiables, sólo que los archivos .bat eran la forma original, y luego aparecieron los comandos .cmd en algún momento (no repetiré todas las largas respuestas anteriores).
Lo que es diferente es la cantidad de memoria asignada.
Estaba tratando de ejecutar una aplicación java en el símbolo del sistema y funcionó con el interruptor java -Xmx2G (darle 2gb de Ram) en su lugar.
Al ejecutarlo programáticamente con un pequeño lote llamado executor.bat obtuve un montón de mensajes de error sobre "Error: No se pudo crear la máquina virtual de Java" y falta de espacio en la pila.
De todas formas, cambiando el executor.bat por executor.cmd se solucionaron todos los problemas. ¡Espero que esto ayude a algún viejo chico del DOS como yo en el futuro!
Michael Burr
Puntos
181287
No - no importa en lo más mínimo. En el NT el .bat y .cmd de extensión, tanto a causa de la cmd.exe procesador para procesar el archivo exactamente de la misma manera.
Adicional información interesante acerca de command.com frente cmd.exe en WinNT sistemas de clase de MS TechNet (http://technet.microsoft.com/en-us/library/cc723564.aspx):
Este comportamiento revela una muy sutil característica de Windows NT, que es muy importante. La 16-bit de shell de MS-DOS (COMMAND.COM) que se incluye con Windows NT está diseñado especialmente para Windows NT. Cuando un comando se introduce para la ejecución de este shell, no en realidad ejecutarlo. En su lugar, paquetes con el comando texto y lo envía para una de 32 bits CMD.EXE shell de comandos para ejecución. Porque todos los comandos son en realidad ejecutado por CMD.EXE (el Windows NT shell de comandos), el 16-bit shell hereda todas las características y instalaciones de Windows NT shell.
David Gray
Puntos
81
RE: al Parecer, cuando command.com se invoca es un poco de un complejo misterio;
Hace algunos meses, durante el curso de un proyecto, hemos tenido que averiguar por qué algunos de los programas que queremos que se ejecute bajo CMD.EXE fueron, de hecho, que se ejecuta bajo COMMAND.COM. El "programa" en cuestión era un viejo archivo .BAT, que todavía se ejecuta a diario.
Hemos descubierto que la razón de que el archivo de proceso por lotes corrió bajo COMMAND.COM es que era que se inició a partir de un archivo .PIF (también a los antiguos). Desde la especial configuración de la memoria de configuración disponibles sólo a través de un PIF se han vuelto irrelevantes, se reemplazó con una convencional de acceso directo en el escritorio.
El mismo archivo por lotes, que se inicia desde el acceso directo se ejecuta en CMD.EXE. Cuando usted piensa acerca de ello, esto tiene sentido. La razón por la que nos tomó tanto tiempo para averiguar fue parcialmente debido al hecho de que nos habíamos olvidado de que su elemento en el grupo de inicio fue un PIF, porque había estado en la producción desde 1998.
