バッチ処理ではなくPowerShellを使おう!

PowerShellはすでにバッチ処理（Cmd.exeシェルスクリプト）の正当な代替品となっているはずですが、様々な理由からバッチ処理を捨てようとしない人が多いようです。本記事は、バッチ処理の習慣を断ち切り、PowerShellに移行するための連載の始まりとなるものです。

これらの記事シリーズに入る前に、バッチファイルの歴史と、なぜ旧式のバッチコードではなくPowerShellを使ってスクリプトを書く必要があるのかを少しお話したいと思います。

バッチファイルの歴史

バッチファイルの歴史は古く、マイコンOSのCP/Mとして、テキストファイルに書かれた一連のコマンドを1行ずつ実行するコミッタブルコマンドを搭載していました。非常にシンプルで（メモリが逼迫していたため）、条件分岐の類はサポートされていなかった。

MS-DOSが開発されたとき、マイクロソフトはCommand.comコマンドインタプリタに非常によく似たバッチ機能を取り入れた。コマンドを.Batという拡張子を持つテキストファイルに格納し、コマンドインタプリタはその中の各コマンドを実行するのである。

DOSの後のバージョンで、マイクロソフトはバッチファイルを様々な方法で拡張した。タグ、GOTOステートメント、Ifステートメントが追加され、分岐を処理できるようになった。重要なのは、バッチ言語が設計されたわけではないことです。CP/Mのコミッタブルコマンドから生まれただけなのです。

Windows NTとCmd.exe

cmd.exeは、MS-DOSの古いCommand.comのスーパーセットで、同じコマンドの多くを使用することさえあります。Cmd.exeは、.Bat拡張子を持つバッチファイル("batch file")を実行することも可能です。

Cmd.exe と Command.com の類似点は .Bat ファイルとの後方互換性で、マイクロソフトが最初に選んだ Cmd.exe のアイコン ("MS-DOS" ロゴ) はユーザーに長年にわたる混乱を引き起こした。今日でも、いくつかのフォーラム・コミュニティで、実際にはDOSには関係ないことなのに、「DOSで何をどうすればいいのか」という質問を見かけることがあります。

Cmd.exe は Command.com よりも多くの機能を持っており、それに応じてバッチファイルの拡張子も多くなっています。For /f の繰り返し、Call コマンドによるサブルーチンの呼び出し、環境の指定（Setlocal と Endlocal）などが含まれます。これらの拡張により、バッチ言語がより便利になったとはいえ、単純なバッチ・プログラムを書くのに頭を悩ませる多くの欠点がある。

Windowsスクリプトホスト

Windows 2000 (1999)から、マイクロソフトはWindows Script Hostを導入してスクリプト機能を強化し、2つの真の組み込み型プログラマブル言語（VBScriptとJScript、マイクロソフト版のローJavascript）を導入しました。WSHスクリプトは、オペレーティングシステムとアプリケーションの間で相互作用するためにCOMオブジェクトに依存しています。WSHは非常に便利で強力ですが、必要なCOMオブジェクトをマシンにインストールする必要があり、コマンドラインインターフェイスを提供しないという点で制限があります。

Windows PowerShellにアクセスする

バッチスクリプトとWSHスクリプトは、異なるユーザーインターフェースを持つ2つの独立した強化ツールだったため、一貫性がありませんでした（バッチスクリプトとWSHスクリプトは別物です）。Microsoftはこれを認識し、2006年にWindows PowerShellの最初のバージョンをリリースし、勢力争いに終止符を打ち、Windowsスクリプトジャングルを統一しました。powerShellは.NETフレームワークをベースに、コマンドライン、およびWindowsオペレーティングシステムを管理するインターフェースを提供しています。

Windows PowerShellがある今、昔ながらのバッチファイル（Cmd.exeシェルスクリプト）を書く必要はない。今後、PowerShellの習得に力を入れるべきですが、それは主にMicrosoftがPowerShellをWindows OSの自動化とエンタープライズアプリケーション管理のためのデフォルトツールとして位置付けているからです。

なぜバッチを書くのをやめる時が来たのか

バッチファイルを書くのをやめて、PowerShellスクリプトに移行すべき5つの理由を説明します。

1. PowerShellは未来であり、ベンチマークである。Microsoftは、PowerShellをWindows OSおよびMicrosoftエンタープライズアプリケーション管理のためのデフォルトツールとして位置づけています。また、多くのサードパーティベンダが、自社製品を管理するためのPowerShellクラスライブラリを提供しています。
2. バッチ処理は不明瞭であり、欠点も多い。以前、某スクリプト質問サイトに行って、「なぜ環境変数が正しく展開されないのか」「なぜコマンドが正しく実行されないのか」という質問を何度したことか。cmd.exeに身を費やす必要は本当にない。バッチ処理には限界がありすぎるので、PowerShellの腕の見せ所です!
3. PowerShellは、バッチとコマンドラインをサポートしています。PowerShellに移行したからといって、バッチ処理を放棄するわけではありません。昔ながらのバッチファイルは今でもPowerShell上で問題なく動作しますし、コマンドラインツールは今でもPowerShell上で完全に互換性を持って動作します。
4. PowerShellは真のスクリプトプログラミング言語です。特に、CMD.exeよりもPowerShellの方が圧倒的に簡単な複雑なロジックを経験しようとすると、PowerShellの甘さをまだ味わっていないかもしれませんね。何度も言いますが、PowerShellのコマンドライン1つで、何百、何千ものバッチコードを置き換えることができるのです。
5. PowerShellはオブジェクトを使用します。Cmd.exeや他のテキストベースのShellと異なり、テキストベースのコマンド出力しか使用できません。一方、PowerShellは.NETオブジェクトを使うので、バッチ処理では厄介だった問題（日付や時間の解析など）が、PowerShellでは驚くほど簡単にできるようになります。

バッチ処理を捨てる

Cmd.exeはすぐには消えませんが、この古いバッチ言語をわざわざ使う理由はありません、捨てて、代わりにPowerShellを使いましょう