バッチファイル

In MS-DOS, a batch file can be started from the command-line interface by typing its name, followed by any required parameters and pressing the ↵ Enter key. When DOS loads, the file AUTOEXEC.BAT, when present, is automatically executed, so any commands that need to be run to set up the DOS environment may be placed in this file. Computer users would have the AUTOEXEC.BAT file set up the system date and time, initialize the DOS environment, load any resident programs or device drivers, or initialize network connections and assignments.

A .bat file name extension identifies a file containing commands that are executed by the command interpreter COMMAND.COM line by line, as if it were a list of commands entered manually, with some extra batch-file-specific commands for basic programming functionality, including a GOTO command for changing flow of line execution.

Microsoft Windows was introduced in 1985 as a graphical user interface-based (GUI) overlay on text-based operating systems and was designed to run on DOS. In order to start it, the WIN command was used, which could be added to the end of the AUTOEXEC.BAT file to allow automatic loading of Windows. In the earlier versions, one could run a .bat type file from Windows in the MS-DOS Prompt. Windows 3.1x and earlier, as well as Windows 9x invoked COMMAND.COM to run batch files.

The IBMOS/2 operating system supported DOS-style batch files. It also included a version of REXX, a more advanced batch-file scripting language. IBM and Microsoft started developing this system, but during the construction of it broke up after a dispute; as a result of this, IBM referred to their DOS-like console shell without mention of Microsoft, naming it just DOS, although this seemingly made no difference with regard to the way batch files worked from COMMAND.COM.

OS/2's batch file interpreter also supports an EXTPROC command. This passes the batch file to the program named on the EXTPROC file as a data file. The named program can be a script file; this is similar to the #! mechanism used by Unix-like operating systems.

Windows 98以前のOSとは異なり、 Windows NTファミリーのオペレーティングシステムはMS-DOSに依存していません。Windows NTでは、拡張子が.CMDまたは.BATのスクリプトを実行できる、拡張された32ビットコマンドインタープリタ（cmd.exe）が導入されました。cmd.exeはコマンドを追加し、既存のコマンドも若干異なる方法で実装したため、同じバッチファイル（拡張子が異なる場合）でもcmd.exeとCOMMAND.COMでは動作が異なる場合があります。サポートされていない少数のコマンドを使用しない限り、ほとんどの場合、動作は同じです。互換性のために、cmd.exeのCOMMAND.COMへの拡張機能を無効にすることができます。

マイクロソフトは、Windows 9xおよびME向けにWIN95CMDと呼ばれるcmd.exeのバージョンをリリースし、古いバージョンのWindowsのユーザーが特定のcmd.exe形式のバッチファイルを使用できるようにした。

Windows 8以降cmd.exe はバッチファイルの通常のコマンドインタープリタです。古い COMMAND.COM も、16 ビット プログラムを実行できる 32 ビット版 Windows で実行できます。^{[ nb 1 ]}

インタープリタは、最初の行から順に各行を実行します。@行の先頭にある記号は、そのコマンドが実行されるときにプロンプ​​トにそのコマンドが表示されないようにします。このコマンドは、ECHO OFFプロンプトを永久にオフにするか、再びオンになるまでオフにします。この組み合わせは、@ECHO OFF多くの場合、ここに示されているようにバッチ ファイルの最初の行であり、自身を含め、どのコマンドも表示されないようにします。次に、次の行が実行され、ECHO Hello World!コマンドは を出力しますHello World!。次の行が実行され、PAUSEコマンドが表示されPress any key to continue . . .、スクリプトの実行が一時停止します。キーが押されると、コマンドがなくなるため、スクリプトは終了します。Windows では、スクリプトが既に実行中のコマンド プロンプトウィンドウから実行されると、MS-DOS と同様にプロンプ​​トでウィンドウが開いたままになります。そうでない場合は、終了時にウィンドウが閉じます。

変数展開はコマンドにテキストとして代入されるため、何も含まれていない変数は構文から消え、スペースを含む変数は複数のトークンに変換されます。これは構文エラーやバグの原因となる可能性があります。

例えば、%foo% が空の場合、このステートメントは次のようになります。

IF %foo% == bar ECHO等しい 

誤った構造として解析されます。

IF ==bar ECHO 等しい

同様に、%foo%が含まれている場合abc def、別の構文エラーが発生します。

IF abc def == bar ECHO等しい 

この問題を回避する一般的な方法は、変数展開を引用符で囲むことです。そうすることで、空の変数がIF ""=="bar"無効な式ではなく、有効な式に展開されますIF ==bar。変数と比較されるテキストも引用符で囲む必要があります。なぜなら、引用符は特別な区切り記号ではなく、それ自体を表す文字だからです。

IF " %foo% " == "bar" ECHO等しい 

Windows 2000以降で利用可能な遅延!VARIABLE!展開を使用すると、これらの構文エラーを回避できます。この場合、値がIFコマンドの解析後に展開されるため、null変数や複数単語の変数でも構文エラーにはなりません。

IF !foo! == bar ECHO等しい 

Windows 2000以降では、空の変数（未定義）が置換されないという違いがあります。前の例で説明したように、以前のバッチインタープリタの動作では空の文字列が生成されていました。例：

C:\> set MyVar = C:\> echo %MyVar% %MyVar%C:\> if " %MyVar% " == "" ( echo MyVar は定義されていません) else ( echo MyVar は%MyVar%です)​​ MyVar は %MyVar% です

Windows 2000 より前のバッチ インタープリタでは、結果が表示されていましたMyVar is not defined。

Unix/POSIXプロセスは、シェルによって既に文字列の配列に分割されたコマンドライン引数を受け取りますが、WindowsプロセスはGetCommandLine API関数を介して、コマンドライン全体を単一の文字列として受け取ります。そのため、各Windowsアプリケーションは、コマンドライン全体を引数に分割するための独自のパーサーを実装できます。多くのアプリケーションやコマンドラインツールは、このための独自の構文を発展させてきたため、 Windowsコマンドラインにおけるメタ文字の引用符付けやエスケープに関する統一された規則は存在しません。

• 一部のコマンドでは、スペースが引用符で囲まれていない限り、スペースは引数を区切る区切り文字として扱われます。引用符をアプリケーションに渡す方法については、さまざまな慣例が存在します。
  • 広く使われている慣例は、Microsoft Visual C++ ランタイム ライブラリに組み込まれているコマンドライン パーサー、または CommandLineToArgvW 関数で実装されています。この慣例では、2 n 個のバックスラッシュの後に引用符 ("") が続くと、 n個のバックスラッシュの後に開始/終了引用符が生成され、(2 n )+1 個のバックスラッシュの後に再び引用符が続くと、n 個のバックスラッシュの後に引用符リテラルが生成されます。同じ慣例は.NET Framework仕様の一部です。^{[ 7 ]}
    • 文書化されていない点として、引用符で囲まれた文字列の途中に""があると、単一の引用符が生成されます。 ^{[ 7 ]} (2008 年の CRT の変更 [msvcr90] により、この文書化されていない引用符の処理が変更されました。^{[ 8 ]} ) これは、|、&、 >などの cmd メタ文字の解釈を再度有効にすることなく、引数に引用符を挿入するのに役立ちます。(cmd は通常の\" を引用符のエスケープとして認識しません。引用符を見ると、引用符が終了したとみなして、これらの特別な意味を再度有効にします。)
  • もう一つの慣例として、単一引用符（"）は文字列の一部として含まれません。ただし、エスケープされた引用符（"""）は文字列の一部として含めることができます。
  • また、 Cygwin由来の移植プログラムの使用から、別の一般的な慣習が生まれています。これは、バックスラッシュが引用符の前にあるかないかを区別しません。これらの代替コマンドラインパーサーについては、glob (プログラミング) §  Windows および DOS を参照してください。 ^{[ 9 ]}
  • cmd.exeや のような重要な Windows コマンドの中には、wscript.exe独自のルールを使用するものがあります。^{[ 8 ]}
• その他のコマンドでは、スペースは区切り文字として扱われないため、引用符は必要ありません。引用符が含まれている場合は、文字列の一部になります。これは、 echoなどの一部の組み込みコマンドに適用されます。

文字列に引用符が含まれており、その文字列を引用符で囲む必要のある別の行のテキストに挿入する場合、引用符の仕組みに特に注意を払う必要があります。

C:\> set foo = "この文字列は引用符で囲まれています"C:\> echo "test 1 %foo% " "test 1 "この文字列は引用符で囲まれています"C:\> eventcreate /T Warning /ID 1 /L System /SO "Source" /D "Example: %foo% "エラー: 無効な引数/オプション - 'string'。使用方法については「EVENTCREATE /?」と入力してください。

Windows 2000以降では、値の中にある引用符文字を、3つの引用符文字の連続に置き換えることで解決できます。

C:\> set foo = "この文字列は引用符で囲まれています"C:\> set foo = %foo:"="""%C:\> echo "test 1 %foo% " "test 1 """この文字列は引用符で囲まれています""""C:\> eventcreate /T Warning /ID 1 /L System /SO "Source" /D "Example: %foo% "成功: 'Source' ログ/ソースに 'Warning' タイプのイベントが作成されました。

パイプ記号（）などの一部の文字は|、コマンドラインにおいて特別な意味を持ちます。これらの文字は、キャレット記号（^）でエスケープしない限り、ECHOコマンドでテキストとして出力することはできません。

C:\> echo foo | bar 'bar' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されません。C:\> echo foo ^| bar foo | bar

しかし、エスケープ文字を環境変数に挿入する場合、エスケープ処理は期待どおりに機能しません。単にエコーするだけで、変数には有効なパイプコマンドが含まれてしまいます。変数内の文字をテキストとして表示するには、キャレット自体とエスケープ文字の両方をエスケープする必要があります。

C:\> set foo = bar | baz 'baz' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されません。C:\> set foo = bar ^| baz C:\> echo %foo% 'baz' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されません。C:\> set foo = bar ^^^| baz C:\> echo %foo% bar |バズ

Windows 2000以降で利用可能な遅延展開は、環境変数に格納されている特殊文字を表示するために使用できます。これは、コマンドが解析された後に変数の値が展開されるためです。

C:\> cmd /V:ON Microsoft Windows [バージョン 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.C:\> set foo = bar ^| baz C:\>エコー!foo!バー |バズ

Windows VistaでTIMEOUTコマンドが導入されるまでは、PAUSEコマンドはキーが押されるまでスクリプトの動作を無期限に停止してしまうため、時間指定の一時停止を簡単に実装する方法はありませんでした。

多くの回避策は可能でしたが、^{[ 10 ]}一般的には一部の環境でしか機能しませんでした。CHOICE古い DOS バージョンではコマンドが利用できず、PINGTCP/IP がインストールされている場合にのみ利用可能でした。Microsoft からは解決策は提供されていませんでしたが、他のソースからいくつかの小さなユーティリティ プログラムをインストールできました。商用の例としては、1 秒間待機する 1988 の Norton Utilities Batch Enhancer (BE) コマンドや、5 秒間待機してからスクリプトに制御を戻すBE DELAY 1894 バイトの無料 WAIT.COM ^{[ 11 ]}WAIT 5があります。このようなプログラムのほとんどは 16 ビットの .COM ファイルであるため、64 ビット Windows と互換性がありません。

通常、印刷されたテキストには、各行の末尾に自動的にキャリッジリターン（CR）とラインフィード（LF）の制御文字が付加されます。

• batchtest.bat

  @ echo foo @ echo bar 

  C:\> batchtest.bat foo bar

2つのechoコマンドが同じコマンド行を共有していても問題ありません。CR/LFコードは、出力を別々の行に分割するために挿入されます。

C:\> @ echoメッセージ 1 &@ echoメッセージ 2 メッセージ 1メッセージ 2

Windows 2000以降で発見されたテクニックとして、入力用の特別なプロンプトを使用して、テキストの末尾にCR/LFを付けずにテキストを出力する方法があります。この例では、CR/LFはメッセージ1の後には付きませんが、行2と行3の後には付きます。

• batchtest2.bat

  @ echo off set /p = "メッセージ 1" < nul echoメッセージ 2 echoメッセージ 3 

  C:\> batchtest2.bat メッセージ1 メッセージ2メッセージ3

これは、末尾にCR/LFを追加せずにテキストファイルにデータを出力する場合に使用できます。

C:\> set /p = "メッセージ 1" < nul > data.txt C:\> set /p = "メッセージ 2" < nul >> data.txt C:\> set /p = "メッセージ 3" < nul >> data.txt C:\> type data.txt メッセージ 1 メッセージ 2 メッセージ 3

しかし、CR/LFが削除されたこのプロンプト出力を環境変数に直接挿入する方法はありません。

UNC パスを現在の作業ディレクトリとして使用するコマンド プロンプトは存在しません。例:\\server\share\directory\

コマンドプロンプトでは、作業ディレクトリを割り当てるためにドライブ文字を使用する必要があるため、サーバーの UNC 共有に保存されている複雑なバッチ ファイルを実行するのが難しくなります。バッチ ファイルは UNC ファイル パスから実行できますが、作業ディレクトリのデフォルトは ですC:\Windows\System32\。

Windows 2000 以降では、回避策として、コマンド拡張機能付きのコマンドPUSHDとPOPDコマンドを使用します。^{[ nb 2 ]}

デフォルトで有効になっていない場合、コマンド拡張機能は/E:ONコマンドインタープリタのスイッチを使用して一時的に有効にすることができます。

UNC共有上でバッチファイルを実行するには、UNC共有に一時的なドライブ文字を割り当て、UNC共有をバッチファイルの作業ディレクトリとして使用するように、次のようなWindowsショートカットを作成できます。

• ターゲット：

このショートカットの作業ディレクトリ属性は無視されます。

これは、Windows Vista 以降のユーザー アカウント制御(UAC)に関連する問題も解決します。管理者がログオンしていて UAC が有効になっている場合、右クリックのファイル コンテキスト メニューを使用してネットワーク ドライブ レターからバッチ ファイルを管理者として実行しようとすると、操作が予期せず失敗します。これは、昇格された UAC 特権アカウント コンテキストにはネットワーク ドライブ レターが割り当てられておらず、エクスプローラ シェルやログオン スクリプトを使用して昇格されたコンテキストにドライブ レターを割り当てることができないためです。しかし、上記のPUSHD/POPD構文を使用してバッチ ファイルへのショートカットを作成し、そのショートカットを使用してバッチ ファイルを管理者として実行すると、昇格されたアカウント コンテキストで一時的なドライブ レターが作成されて削除されるため、バッチ ファイルが正しく機能します。

以下の構文は、現在のバッチスクリプトのパスに正しく展開されます。

%~dp0

UNC のデフォルト パスは、古いプログラムがクラッシュする原因となっていたため、デフォルトでは無効になっています。^{[ 12 ]}

^{[ 12 ]}DisableUNCCheckのDword レジストリ値により、デフォルト ディレクトリを UNC にすることができます。コマンドは変更を拒否しますが、Cmd へのショートカットのデフォルト ディレクトリに UNC パスを配置するか、スタート コマンドを使用します。（共有は管理者向けです）。HKEY_CURRENT_USER\Software\Microsoft\Command ProcessorCDC$

バッチ ファイルは、コンピュータによって定義された OEM 文字セット (例:コード ページ 437)を使用します。これらの文字セットの非 ASCII 部分は、 Windows で使用されているUnicodeまたはWindows 文字セットと互換性がないため、注意が必要です。^{[ 13 ]}英語以外のファイル名は、DOS 文字セット互換のエディタで入力した場合にのみ機能します。このセット外の文字を含むファイル名は、バッチ ファイルでは機能しません。

コードページ437などではなくUnicodeを使用したコマンドプロンプトを取得するには、cmd /Uコマンドを使用できます。このようなコマンドプロンプトでは、Unicodeファイル名を含むバッチファイルが動作します。また、Unicodeを文字セットとしてコマンドを直接実行することもできますcmd /U。たとえば、UTF-16 LEエンコーディングで正しいWindows文字を含むディレクトリ一覧を記述したファイルを作成します。cmd /U /C dir > files.txt