arquivos em lote do Windows: .bat vs .cmd?

Question

Pelo que entendi, .bat é a antiga convenção de nomeação de 16 bits, e .cmd é para Windows de 32 bits, ou seja, começando com NT. Mas eu continuo a ver arquivos .bat em todos os lugares, e eles parecem funcionar exatamente o mesmo usando um sufixo. Assumindo que meu código nunca vai precisar para rodar em qualquer coisa mais velha do que NT, isso realmente importa para que lado eu nomeio meus arquivos em lote, ou se há alguma pegadinha me aguardando usando o sufixo errado?

Answer 1

A partir esta notícia grupo postagem por Mark Zbikowski -se:

As diferenças entre .CMD e .BAT, tanto quanto CMD.EXE está em causa são: Com extensões habilitado, PATH / acrescentar / PROMPT / SET / ASSOC em .CMD arquivos irá definir ERRORLEVEL independentemente do erro. .BAT define ERRORLEVEL somente em erros.

Em outras palavras, se ERRORLEVEL é definida para não-0 e, em seguida, você executar um desses comandos, o ERRORLEVEL resultante será:

• deixado sozinho em sua não-0 valor em um arquivo .bat
• redefinir a 0 em um arquivo .cmd.

Answer 2

Aqui é uma compilação de informações verificadas entre as várias respostas e referências citadas neste tópico:

1. command.com é o processador de comando de 16 bits introduzida em MS-DOS e também foi usado na série Win9x de sistemas operativos.
2. cmd.exe é o processador de comandos de 32 bits no Windows NT (64-bit do Windows sistemas operacionais também têm uma versão de 64-bit). cmd.exe nunca foi parte do Windows 9x. Originou-se em OS / 2 versão 1.0, ea versão OS / 2 da cmd começou 16 bits (mas mesmo assim foi um programa de modo pleno direito protegido com comandos como start). Windows NT herdou cmd de OS / 2, mas a versão Win32 do Windows NT começou 32 bits. Embora OS / 2 foi de 32 bits, em 1992, a sua cmd permaneceu a / 2 1.x programa de 16-bit OS.
3. Os define variáveis ??ComSpec env qual o programa é lançado por scripts .bat e .cmd. (Começando com WinNT O padrão é cmd.exe.)
4. cmd.exe é compatível com command.com.
5. Um script que é projetado para cmd.exe pode ser nomeado .cmd para impedir a execução acidental em Windows 9x. Esta extensão do arquivo também remonta a OS / 2 versão 1.0 e 1987.

Aqui está uma lista de características cmd.exe que não são suportados pelo command.com:

• nomes de arquivos longos (superiores o formato 8.3)
• história Comando
• Tab conclusão
• caractere de escape: ^ (Use para: \ & | > < ^)
• Diretório pilha: PUSHD / POPD
• Integer aritmética: SET /A i+=1
• Procura / Substituir / Substring: SET %varname:expression%
• Comando substituição: FOR /F (existia antes, foi aprimorado)
• Funções: CALL :label

Ordem de Execução:

Se ambos .bat e .cmd versões de um script (test.bat, TEST.CMD) estão na mesma pasta e executar o script sem a extensão (teste), por padrão a versão .bat do script será executar, mesmo em 64 bits do Windows 7. a ordem de execução é controlada pela variável de ambiente PATHEXT. Veja Ordem na qual Comando arquivos Executa Prompt para mais detalhes.

Referências:

• cmd.exe
• command.com

wikipedia: Comparação de shells de comando

Answer 3

Estas respostas são um pouco longo demais e focado no uso interativo. As diferenças importantes para scripting são:

• impede .cmd execução inadvertida em sistemas não-NT.
• .cmd permite built-in comandos para mudar ERRORLEVEL a 0 sobre o sucesso.

extensões de comando são por padrão em arquivos tanto .bat e .cmd no Windows 2000 ou posterior.

Em 2012 e além, eu recomendo usar .cmd exclusivamente.

Answer 4

Não - não importa em nada. No NT o .bat e extensão .cmd tanto a causa do processador cmd.exe para processar o arquivo exatamente da mesma maneira.

Informações adicionais interessante sobre command.com http://technet.microsoft.com/en-us/library/cc723564.aspx ):

Este comportamento revela uma muito subtil recurso do Windows NT que é muito importante. Os 16 bits MS-DOS Shell (COMMAND.COM) que vem com o Windows NT é especialmente concebido para Windows NT. Quando um comando é inserido para execução por esta concha, isso não acontece realmente executá-lo. Em vez disso, empacota o texto de comando e envia-lo para um shell de comando CMD.EXE de 32 bits para execução. Porque todos os comandos são realmente executado por CMD.EXE (o shell de comando do Windows NT), o 16-bit shell herda todas as características e instalações do total do Windows NT shell.

Answer 5

RE: Aparentemente, quando command.com é invocado é um pouco de um mistério complexo;

Há vários meses, durante o curso de um projeto, tivemos que descobrir por que alguns programas que queríamos para ser executado sob CMD.EXE eram, na verdade, rodando sob COMMAND.COM. O "programa" em questão era um arquivo .bat muito antiga, que ainda funciona diariamente.

Nós descobrimos que a razão da RAN arquivo de lote sob COMMAND.COM é que ele estava sendo iniciado a partir de um arquivo .pif (também antiga). Desde as configurações especiais de configuração de memória disponível somente através de um PIF se tornaram irrelevantes, que substituiu-o com um atalho no desktop convencional.

O mesmo arquivo de lote, iniciado a partir do atalho, é executado em CMD.EXE. Quando você pensa sobre isso, isso faz sentido. A razão que nos levou tanto tempo para descobrir isso foi parcialmente devido ao fato de que tinha esquecido que o seu item no grupo de arranque foi um PIF, porque tinha estado em produção desde 1998.

Answer 6

Uma vez que o post original foi sobre as consequências do uso do .bat ou .cmd sufixo , e não necessariamente os comandos dentro o arquivo ...

Uma outra diferença entre .bat e .cmd é que se existem dois arquivos com o mesmo nome de arquivo e ambas as extensões, então:

• entrar nome ou nome .bat na linha de comando irá executar o arquivo .bat

• para executar o ficheiro .cmd, você tem que entrar nome .cmd

Answer 7

Ainda assim, no Windows 7, arquivos BAT têm também esta diferença: Se você nunca criar arquivos TEST.BAT e TEST.CMD no mesmo diretório, e você executar o teste nesse diretório, ele vai executar o arquivo BAT <. / p>

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

tudo funcionando em um lote deve trabalhar em um cmd; cmd fornece algumas extensões para controlar o ambiente. Também, cmd é executado pelo no novo interpretador cmd e, portanto, deve ser mais rápido (não visível em arquivos curtos) e Stabler como corridas de morcego sob o NTVDM emulado 16bit ambiente

Answer 9

Eu acredito que se você alterar o valor da variável de ambiente ComSpec para% SystemRoot% system32 \ cmd.exe então não importa se a extensão do arquivo é .BAT ou .cmd. Eu não tenho certeza, mas isso pode até ser o padrão para WinXP e acima.

Answer 10

Um pouco fora do tópico, mas você já pensou Windows Scripting Host ? Você pode encontrá-lo mais agradável.

Answer 11

.cmd e .bat execução de arquivos é diferente porque em uma variável errorlevel .cmd ele pode mudar em um comando que é afetada por extensões de comando. Isso é sobre ele realmente.

Answer 12

A extensão não faz diferença. Existem pequenas diferenças entre COMMAND.COM manipulação do arquivo vs. CMD.EXE

Answer 13

Aqui está uma diferença que eu descobri:. EnableDelayedExpansion é required em arquivos .cmd
Quando, como no caso de arquivos .bat está implícito por padrão. ( Windows 10 )

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

Isso funciona em .bat mas é sempre found em caso de um arquivo .cmd.
Alterar line 2 aos seguintes faz com que funcione como o esperado:

if %ERRORLEVEL% equ 0       (

E, finalmente, para o arquivo .cmd isso funciona corretamente:

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

Answer 14

a diferença:

.cmd são carregados na memória antes de ser executado. arquivos .bat executar uma linha, leia a próxima linha, executar essa linha ...

Você pode se deparar com isso quando você executar um arquivo de script e, em seguida, editá-lo antes que seja feito execução. arquivos BAT será confuso com isso, mas arquivos CMD não.