File batch di Windows: .bat vs .cmd?

A quanto ho capito, .batè la vecchia convenzione di denominazione a 16 bit ed .cmdè per Windows a 32 bit, ovvero a partire da NT. Ma continuo a vedere file .bat ovunque e sembrano funzionare esattamente allo stesso modo usando entrambi i suffissi. Supponendo che il mio codice non dovrà mai essere eseguito su qualcosa di più vecchio di NT, è davvero importante il modo in cui assegno i miei file batch o c'è qualche codice che mi sta aspettando usando il suffisso sbagliato?

Da questo gruppo di notizie pubblicato dallo stesso Mark Zbikowski :

Le differenze tra .CMD e .BAT per quanto riguarda CMD.EXE sono: Con le estensioni abilitate, PATH / APPEND / PROMPT / SET / ASSOC nei file .CMD imposteranno ERRORLEVEL indipendentemente dall'errore. .BAT imposta ERRORLEVEL solo su errori.

In altre parole, se ERRORLEVEL è impostato su un valore diverso da 0 e quindi si esegue uno di questi comandi, ERRORLEVEL risultante sarà:

• lasciato solo al suo valore diverso da 0 in un file .bat
• reimpostato su 0 in un file .cmd.

Ecco una raccolta di informazioni verificate dalle varie risposte e riferimenti citati in questo thread:

1. command.com è il processore di comando a 16 bit introdotto in MS-DOS ed è stato utilizzato anche nella serie di sistemi operativi Win9x.
2. cmd.exeè il processore di comandi a 32 bit in Windows NT (i sistemi operativi Windows a 64 bit hanno anche una versione a 64 bit). cmd.exenon ha mai fatto parte di Windows 9x. È nato in OS / 2 versione 1.0 e la versione OS / 2 di ha cmdiniziato a 16 bit (ma era comunque un programma in modalità protetta a tutti gli effetti con comandi simili start). Windows NT ereditato cmdda OS / 2, ma la versione Win32 di Windows NT è stata avviata a 32 bit. Sebbene OS / 2 sia andato a 32 bit nel 1992, è cmdrimasto un programma OS / 2 1.x a 16 bit.
3. La ComSpecvariabile env definisce quale programma è lanciato da .bate .cmdscript. (A partire da WinNT, l'impostazione predefinita è cmd.exe.)
4. cmd.exeè retrocompatibile con command.com.
5. Uno script progettato per cmd.exepuò essere nominato .cmdper impedire l'esecuzione accidentale su Windows 9x. Questa estensione di file risale anche alla versione 1.0 e 1987 di OS / 2.

Ecco un elenco di cmd.exefunzionalità che non sono supportate da command.com:

• Nomi di file lunghi (superando il formato 8.3)
• Cronologia dei comandi
• Completamento della scheda
• Carattere di escape: ^(utilizzare per \ & | > < ^:)
• Stack di directory: PUSHD/POPD
• Aritmetica intera: SET /A i+=1
• Ricerca / sostituzione / Substring: SET %varname:expression%
• Sostituzione comando: FOR /F(esisteva prima, è stato migliorato)
• funzioni: CALL :label

Ordine di esecuzione:

Se entrambe le versioni .bat e .cmd di uno script (test.bat, test.cmd) si trovano nella stessa cartella e si esegue lo script senza l'estensione (test), per impostazione predefinita verrà eseguita anche la versione .bat dello script, anche su Windows a 64 bit 7. L'ordine di esecuzione è controllato dalla variabile d'ambiente PATHEXT. Vedere Ordine in cui il prompt dei comandi esegue i file per ulteriori dettagli.

Riferimenti:

• cmd.exe
• command.com

wikipedia: confronto delle shell dei comandi

Queste risposte sono un po 'troppo lunghe e focalizzate sull'uso interattivo. Le differenze importanti per lo scripting sono:

• .cmd impedisce l'esecuzione involontaria su sistemi non NT.
• .cmd abilita i comandi integrati a modificare Errorlevel a 0 in caso di successo.

Non è così eccitante, eh?

C'erano un certo numero di funzionalità aggiuntive abilitate nei .cmdfile, chiamate estensioni di comando. Tuttavia, ora sono attivati per impostazione predefinita per entrambi .bate .cmdfile in Windows 2000 e versioni successive.

In conclusione: nel 2012 e oltre, consiglio di utilizzare .cmdesclusivamente.

No, non importa minimamente. Su NT l'estensione .bat e .cmd fanno sì che il processore cmd.exe elabori il file esattamente allo stesso modo.

Ulteriori informazioni interessanti su command.com vs. cmd.exe su sistemi di classe WinNT da MS TechNet ( http://technet.microsoft.com/en-us/library/cc723564.aspx ):

Questo comportamento rivela una caratteristica abbastanza sottile di Windows NT che è molto importante. La shell MS-DOS a 16 bit (COMMAND.COM) fornita con Windows NT è appositamente progettata per Windows NT. Quando un comando viene immesso per l'esecuzione da questa shell, in realtà non lo esegue. Comprime invece il testo del comando e lo invia a una shell dei comandi CMD.EXE a 32 bit per l'esecuzione. Poiché tutti i comandi vengono effettivamente eseguiti da CMD.EXE (la shell dei comandi di Windows NT), la shell a 16 bit eredita tutte le funzionalità e le funzionalità della shell completa di Windows NT.

RE: Apparentemente quando viene chiamato command.com è un po 'un mistero complesso;

Diversi mesi fa, nel corso di un progetto, abbiamo dovuto capire perché alcuni programmi che volevamo eseguire sotto CMD.EXE, in effetti, erano in esecuzione su COMMAND.COM. Il "programma" in questione era un file .BAT molto vecchio, che viene ancora eseguito quotidianamente.

Abbiamo scoperto che il motivo per cui il file batch è stato eseguito in COMMAND.COM è che veniva avviato da un file .PIF (anche antico). Poiché le speciali impostazioni di configurazione della memoria disponibili solo tramite un PIF sono diventate irrilevanti, l'abbiamo sostituito con un collegamento desktop convenzionale.

Lo stesso file batch, avviato dal collegamento, viene eseguito in CMD.EXE. Quando ci pensi, questo ha senso. Il motivo per cui ci è voluto così tanto tempo per capirlo era parzialmente dovuto al fatto che avevamo dimenticato che il suo articolo nel gruppo di avvio era un PIF, perché era in produzione dal 1998.

Tuttavia, su Windows 7, i file BAT hanno anche questa differenza: se si creano file TEST.BAT e TEST.CMD nella stessa directory e si esegue TEST in quella directory, verrà eseguito il file 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>

Poiché il post originale riguardava le conseguenze dell'uso del suffisso .bat o .cmd , non necessariamente i comandi all'interno del file ...

Un'altra differenza tra .bat e .cmd è che se esistono due file con lo stesso nome ed entrambe le estensioni, allora:

• inserendo il nome file o il nome file .bat dalla riga di comando verrà eseguito il file .bat

• per eseguire il file .cmd, devi inserire il nome file .cmd

tutto ciò che lavora in un batch dovrebbe funzionare in un cmd; cmd fornisce alcune estensioni per il controllo dell'ambiente. inoltre, cmd viene eseguito da un nuovo interprete cmd e quindi dovrebbe essere più veloce (non evidente su file brevi) e più stabile quando bat funziona nell'ambiente a 16 bit emulato NTVDM

L'esecuzione dei file .cmd e .bat è diversa perché in una variabile di livello di errore .cmd può cambiare in un comando interessato dalle estensioni di comando. Questo è tutto.

Credo che se cambi il valore della variabile d'ambiente ComSpec in %SystemRoot%system32\cmd.exe(CMD), non importa se l'estensione del file è .BATo .CMD. Non ne sono sicuro, ma potrebbe anche essere il valore predefinito per WinXP e versioni successive.

Leggermente fuori tema, ma hai considerato Windows Scripting Host ? Potresti trovarlo più bello.

L'estensione non fa differenza.

Vi sono lievi differenze tra la COMMAND.COMgestione del file e CMD.EXE.

una differenza:

I file .cmd vengono caricati in memoria prima di essere eseguiti. I file .bat eseguono una riga, leggono la riga successiva, eseguono quella riga ...

puoi trovarlo quando esegui un file di script e poi lo modifichi prima che sia terminata l'esecuzione. i file bat saranno confusi da questo, ma i file cmd no.