この記事では、私自身がバッチファイルを書く時に気をつけていることについて書きます。業務でバッチファイルと関わると「不可解な挙動に心が削られる」「試行錯誤で時間を溶かす」などしますので本来ならバッチファイルに近づかないことの方が先なのですが。

そうはいってもSIerの方などで、不本意にもバッチファイルを書かざるを得ない場面に遭遇してしまうことは少なからずあると思います。そんな人がバッチファイルの落とし穴にハマって貴重な工数を溶かさないことを願ってこの記事を書きました。

なお「環境変数の遅延展開」という言葉にピンとこない方は、@sawa_tsukaさんの素敵な記事「バッチファイル界の魔境『遅延環境変数』に挑む（おまけもあるよ）」を一読されることをオススメします。

まずは記号をおさえよう

バッチファイルでは記号の扱いでドはまりすることが多いです。まずはじめに、どんな記号があるか押さえておきます。

• ファイル名に使用できない記号。→　\ / : * ? " < > |
• ファイル名に使用できる記号。　→　! # $ % & ' ( ) = ~ ` {} + _ - ^ @ [ ; ] , .

といっても、たいていの文字は"..."のようにダブルクォートで囲めばエスケープできるので、ダブルクォートで囲ってさえいれば特に何か注意すべきことはないのですが、例外的に%と"、遅延展開有効時の!は"..."でエスケープができません。

以下では%と"の扱い方について説明します。

「%」について

%は構文解析の冒頭で以下の展開がおこなわれます。

• %%は%に展開される。
• %変数名%または%%単一文字変数名は、変数がもつ値に展開される。
• 単独の%は消滅する。

なので、%をエスケープしたいときは%%とすれば疑似的にエスケープできます。例えば、文字列%foo%をママ表示したいときはecho %%foo%%と書きます。このテクニックはcallの引数に含まれる変数の事前展開を先送りしたいときにも使います。

%の展開は構文解析の最初に行われ、それ以降に展開後文字列に含まれる特殊記号の発動が行われるので、%変数名%を展開した結果の文字列にエスケープされていない特殊記号（^!&|など）が含まれていれば、その処理が発動します。

「"」について

文字列の値を変数に代入するときは、ダブルクォテーションを囲って代入することに決めています。変数を取りまわすとき、特殊記号のエスケープに心を砕きたくないためです。また「文字列はすべてダブルクォートで囲まれている」という前提があると精神的にも楽です。

set foo="Hello, world"

文字列中に「"」は含めない

文字列を囲むものとコメント部分を除き、文字列中にダブルクォテーション（"）を含めることを、私的には禁止しています。なぜなら、バッチファイルでのダブルクォテーションの取り扱いは異常に難しいためです。ただ1個の"があるだけで、それを含む文全体のシンタックスを崩壊させる力をもつのです。

どれぐらい難しいかというと、、、
例えば、一個の"を含む文字列を扱ってみましょう。

set foo="aaa"bbb"
if %foo%=="aaa"bbb" (
    echo matched
)

( の使い方が誤っています。

>if "aaa"bbb"=="aaa"bbb" (

上記では「if文の条件部に"aaa"bbb"=="aaa"bbb"という一続きの文字列が置かれている」と解釈されたようす。では、文字列中のダブルクォテーションを^"とエスケープすれば解決するかというと…

if %foo%=="aaa^"bbb" (
    echo matched
)

コマンドの構文が誤っています。

>if "aaa^"bbb"=="aaa^"bbb" (

解決しないです。上記では行末の(まで含めて文字列リテラルとして扱われているみたいですが。

…とまあ「〇〇をしたい時、どう書くのが正解なのか」を探り当てるのに非常に時間がかかるわけです。

バッチファイルに熟練すればダブルクォテーションを自在に取りまわすやり方はあるのかもしれないですが、仮にあるとしてもトリッキーな方法であることは予想されるし、そうすると必ず事故を起こすでしょう。保守のことも考えると（文字列囲みやコメント部分以外の）ダブルクォテーションの使用は禁止としたほうが精神的に楽かと思います。

バッチファイルのプロローグ

@echo off
cd %~dp0

@echo off
pushd %~dp0

@echo off
setlocal
set CurrentDirectory="%~dp0"

解説

• 冒頭でsetlocalしておけば、バッチ終了時までに対応するendlocalが実行されない場合、バッチ終了時に暗黙的にendlocalが呼ばれます。つまり、バッチファイル内の変数スコープが外に漏れることがありません。
• パスに&が含まれている場合、setコマンドの行で&より後の文字列をコマンドとみなして実行してしまいます。そのため"%~dp0"のようにパス全体をダブルクォテーションで囲むことにしています。
• バッチファイル自体がUNCパス（\\ServerName\SharedFolder形式のパス）上に配置して実行された場合、cd /dではUNCパスには移動できませんので、pushdを使うという手法があります…が、これですとバッチファイルが異常終了したときにドライブレターの割り当てがゴミとして残ってしまう問題があります。ユーザの実行環境を汚したくない場合はpushdは使わず、ファイルパスは絶対パス指定で取りまわすようにしています。

関数呼出し

    set fileName="C:\folder\%%xxx%%.txt"
    call :func %fileName%

call文の実行にさいしては構文解析が2回行われます。1回目の構文解析では変数%fileName%がC:\folder\%xxx%.txtに展開されますが、さらに2回目の構文解析で%xxx%が展開されます。しかしxxxという名前の変数は存在しないため%xxx%はブランクに展開され、最終的にcall :func "C:\folder\.txt"というコマンドが実行されることになります。

そこでcall文で引数に変数を指定する場合、%変数名%ではなく%%変数名%%とします。

    set fileName="C:\folder\%%xxx%%.txt"
    call :func %%fileName%%

call文の1回目の構文解析で%fileName%を展開させないため、%%と2つにしています。こうすれば、1回目の構文解析は%%が%に展開されるのみにとどまり、2回目の構文解析で%fileName%が"C:\folder\%xxx%.txtに展開されます。

また、call文の引数に「ダブルクォートで囲まれた文字列」を指定したとき、その文字列にサーカムフレックス（^）が含まれると、そのサーカムフレックス1個につき2個に増える（^^）という現象があります。その展開を回避する意味もあります。詳細は「バッチファイルでの試行錯誤を回避するためのメモ#サーカムフレックスの不思議」を参照下さい。

環境変数の遅延展開で気をつけたいこと

setlocal enabledelayedexpansionで遅延展開を有効にした場合、%変数名%を事前展開した結果に!文字列!が含まれるとき、さらに!文字列!が遅延展開され、予期しない結果となる場合があります。これは単一文字変数（例：%%A）についても例外ではありません。

回避方法は「SetLocal EnableDelayedExpansionの罠とその回避方法」を参照下さい。

forやdirでのワイルドカードのマッチング

dir *.xmlやfor %%A in (*.xml)のようにしてワイルドカード指定で検索するとき、内部的にはファイル名の8.3形式とロングネーム形式でのOR条件でのマッチングがおこなわれるようです。例えばdir *.xmlを実行してXMLファイルのみをリストアップしたつもりでも、拡張子.xml_のファイルもリストに含まれてしまいます。

forfilesコマンドの/Mオプションはロングネーム形式でのマッチングとなりますので、検索用途ではforfilesがおすすめです。