Domanda

A quanto ho capito, .bat è la vecchia convenzione di denominazione a 16 bit e .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 gotcha che mi sta aspettando usando il suffisso sbagliato?

È stato utile?

Soluzione

Da la pubblicazione di questo gruppo di notizie di Mark Zbikowski stesso:

  

Le differenze tra .CMD e .BAT per quanto riguarda CMD.EXE   sono: con le estensioni abilitate, PERCORSO / APPEND / PROMPT / SET / ASSOC in .CMD   i file imposteranno ERRORLEVEL indipendentemente dall'errore. .BAT imposta ERRORLEVEL   solo in caso di 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
  • ripristinato a 0 in un file .cmd.

Altri suggerimenti

Ecco una raccolta di informazioni verificate dalle varie risposte e riferimenti citati in questa discussione:

  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 (anche i sistemi operativi Windows a 64 bit hanno una versione a 64 bit). cmd non ha mai fatto parte di Windows 9x. È nato in OS / 2 versione 1.0 e la versione OS / 2 di start ha iniziato a 16 bit (ma era comunque un programma in modalità protetta a tutti gli effetti con comandi come ComSpec). Windows NT ha ereditato .bat da OS / 2, ma la versione Win32 di Windows NT è stata avviata a 32 bit. Sebbene OS / 2 sia andato a 32 bit nel 1992, il suo .cmd è rimasto un programma OS / 2 1.x a 16 bit.
  3. La variabile env definisce quale programma viene lanciato dagli script ^ e \ & | > < ^. (A partire da WinNT, l'impostazione predefinita è PUSHD.)
  4. POPD è retrocompatibile con SET /A i+=1.
  5. Uno script progettato per SET %varname:expression% può essere denominato FOR /F per impedire l'esecuzione accidentale su Windows 9x. Questa estensione di file risale anche a OS / 2 versione 1.0 e 1987.

Ecco un elenco di CALL :label funzioni che non sono supportate da <=>:

  • Nomi di file lunghi (che superano il formato 8.3)
  • Cronologia dei comandi
  • Completamento scheda
  • Carattere di escape: <=> (Utilizzare per: <=>)
  • Stack di directory: <=>/<=>
  • Aritmetica intera: <=>
  • Cerca / Sostituisci / Sottostringa: <=>
  • Sostituzione comando: <=> (esisteva prima, è stato migliorato)
  • Funzioni: <=>

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 la versione .bat dello script verrà eseguire, anche su Windows 7. a 64 bit. L'ordine di esecuzione è controllato dalla variabile d'ambiente PATHEXT. Vedi Ordine in cui il prompt dei comandi esegue i file per maggiori dettagli.

References:

wikipedia: Confronto di 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.
  • <=> abilita i comandi integrati per modificare Errorlevel a 0 in caso di successo.

Le estensioni di comando sono attive per impostazione predefinita nei file .bat e .cmd in Windows 2000 o versioni successive.

Nel 2012 e oltre, raccomando di utilizzare <=> esclusivamente.

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 si rivela abbastanza sottile   funzionalità di Windows NT che è molto   importante. La shell MS-DOS a 16 bit   (COMMAND.COM) fornito con Windows   NT è appositamente progettato per Windows   NT. Quando viene inserito un comando per   esecuzione da questa shell, non lo fa   eseguirlo effettivamente. Invece   impacchetta il testo del comando e lo invia   a una shell dei comandi CMD.EXE a 32 bit per   esecuzione. Perché tutti i comandi sono   effettivamente eseguito da CMD.EXE (il   Shell dei comandi di Windows NT), il 16 bit   shell eredita tutte le funzionalità e   strutture dell'intero Windows NT   shell.

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 erano, infatti, in esecuzione sotto COMMAND.COM. Il & Quot; programma & Quot; 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 era stato 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 startup era un PIF, perché era in produzione dal 1998.

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

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

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

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

Tuttavia, su Windows 7, i file BAT presentano 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>

tutto ciò che funziona 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

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

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

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.

L'estensione non fa differenza. Esistono lievi differenze tra COMMAND.COM che gestisce il file rispetto a CMD.EXE

Ecco una differenza che ho scoperto: EnableDelayedExpansion è richiesto in .cmd file.
Dove come nel caso di .bat file è implicito per impostazione predefinita. ( Windows 10 )

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

Funziona in found ma è sempre line 2 nel caso di un <=> file.
La modifica di <=> in quanto segue fa funzionare come previsto:

if %ERRORLEVEL% equ 0       (

E infine per il file <=> funziona correttamente:

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

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 incasinati, ma i file cmd no.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top