\r\n\r\n
ほとんどのユーザーは、PowerShellを触ったことも試したこともないどころか、聞いたこともない。これは、その名前が、筋金入りのITオタクしか使わないような響きだからかもしれません。あるいは、PowerShellのメリットが明確でないからかもしれません。それは、最初に学習するためかもしれません。
実際、そうです、ほとんどの一般的なコンピュータ・ユーザーはPowerShellの力を必要としません。しかし、もしあなたがプログラミングの経験があるなら、あるいはグラフィカルなウィンドウよりもコマンドラインを好むなら、あるいはスクリプトを使ってタスクを自動化するのが好きなら、PowerShellが提供するものを気に入るはずです。
要するに、バッチスクリプトでコマンドプロンプトをなぞり、ちょっとした機能を追加して、数段上のものにすると、PowerShellが出来上がるということです。気になる?ここでは、それを試してみるべきいくつかの確かな理由を紹介します。
PowerShellスクリプトは、バッチスクリプトと同様に、プレーンテキストファイルにコマンドラインを書き込むだけですが、ファイルの拡張子が.BATや.CMDではなく、.PS1であることが特徴です。しかし、似ているのはそこだけです。
バッチスクリプトには、コマンドプロンプトからのコマンドしか使えないという大きな制約があります。言い換えれば、バッチスクリプトは、コマンドプロンプトのコマンド(いくつかの条件付きロジックを含む)を並べたものに過ぎないのです。これは原始的な作業や単純な自動化には向いていますが、複雑なことをしたいときには本当にハンディキャップです。
一方、PowerShellスクリプトは、PowerShellスクリプト言語という真のプログラミング言語を使って書かれており、本当に高度なタスクのための詳細なロジックを提供します。言語自体は、特にプログラミングの経験があれば簡単に習得できますが、変数、関数、ループ、例外処理など、さまざまな機能がサポートされています。
ここでもう一つ注目したいのは、PowerShell ISE(Integrated Scripting Environment)が、通常のコマンドプロンプトよりも大幅に改善されている点です。シンタックスハイライト、オートコンプリート、タブ編集、文脈依存ヘルプなど、スクリプトを書くときにとても便利なQOL(クオリティ・オブ・ライフ)機能を備えています。
つまり、PowerShellはより良いスクリプトを書けるだけでなく、より速く書けるようになるのです。
PowerShellのパワーと柔軟性の多くは、.NET Frameworkとの統合によってもたらされます。PosiShellの各コマンド(CMDLetと呼ぶ)は、実際には実行時に呼び出される.Netクラスであり、CMDLetはどの.NET言語でも書くことができる(今回はVisualBasic、VisualC++、Cを含む)ことを意味します。
では、.NET APIに対応することで、どのようなメリットがあるのでしょうか。
.NETのAPIは、標準クラスライブラリのセットに整理された素晴らしいユーティリティや関数でいっぱいです。このようなAPIの側面を利用することで、入力の収集やデータの管理といったことを、自分でヘルパーをすべて書き換えなくても行うことができます。
また、PowerShellは、.NET APIやPowerShellに組み込まれたさまざまなプロバイダを利用して、ファイルシステム、レジストリ、証明書ストアなど、Windowsエコシステムの最も深い部分まで掘り下げることができます。その結果、PowerShellコマンドレットとスクリプトは、単なるバッチスクリプト以上のことができるようになりました。
おそらく最も興味深いのは、PowerShellでは、あるコマンドレットの出力をオブジェクトとして別のコマンドレットにパイプできることです。他のほとんどのシェル(Bashを含む)では、あるコマンドから別のコマンドに情報を渡すことはプレーンテキストでしかできませんが、PowerShellのアプローチはよりクリーンでコンパクト、そしてエラーが起こりにくいです。
上記の理由でも納得できないなら、きっとこの理由があるはずです。
PowerShellはコマンドプロンプトの上に構築されているわけではありません。2つのシェルの根本的なアーキテクチャは全く異なるので、PowerShellを「コマンドプロンプト2.0」などと考えるのは技術的に間違っています。しかし、PowerShellは後方互換性があるように設計されています。
コマンドプロンプトで使用する一般的なコマンドは、ほとんどPowerShellで使用することができます。PowerShellにはコマンドレットに相当するものが組み込まれており、そのスクリプトはこれらのコマンドと全く同じ動作を行うことができますが、エイリアスを使用して古いコマンド名と新しいコマンドレットを「リンク」させています。
例えば、PowerShellでcdを実行すると、実際にはSet-Locationコマンドレットを実行していることになりますが、この場合、「cd」は単に「Set Location」の別名であるため、より簡単に操作することができます。これによって、あなたの生活がより快適になります。同様に、PowerShellでrenameを使用すると、rename-Itemコマンドレットが密かに実行されます。
つまり、当然のことながら、PowerShellでバッチスクリプトを実行できるため、すべてを完全に捨てなくてもバッチスクリプトからPowerShellスクリプトに移行することができるのです。
PowerShellは2006年に初めて発表されました。それから10年以上経った今、マイクロソフトの最も重要なプロジェクトの一つにまで成長しました。これをサポートするチームは、このシェルを最高のものにするために懸命に働いており、マイクロソフトは、特にIT専門家の間でこのシェルの採用を促進するために最善を尽くしています。
今後、PowerShellはWindowsやマイクロソフトのエンタープライズ製品におけるタスクやアプリケーションを自動化するための主要な手法になると思われます。これは非常に重大な動きで、サードパーティベンダーでさえ、ソフトウェアの管理やトラブルシューティングに役立つPowerShellライブラリを提供し始めています。
しかし、最も重要なのは、Microsoftが一部の資格試験にPowerShell関連の問題を追加していることです。実際、2009年のTechNet誌のインタビューによると、Microsoftは、"Windows管理者が今後必要とする最も重要なスキルは、Windows PowerShellの熟練度である "と述べている。
ですから、あなたが上級ホームユーザーであろうと、Windowsシステムを管理するITプロフェッショナルであろうと、バッチスクリプトは時代遅れで、PowerShellが未来なのだと受け入れるべきなのです。
2014年には.NETフレームワークをオープンソース化し、複数のプラットフォームで利用できるようにしました。そして2016年、windows 10にBashシェルをネイティブ統合した。
2017年、LinuxへのPowerShellインストールは、かつてないほど簡単になりました。本稿執筆時点では、Microsoftは現在、ほとんどの主要なバージョンのLinuxにPowerShell Coreをインストールできるパッケージリポジトリを用意しており、お使いのシステムがapt-getやyumをサポートしていれば、おそらく簡単にインストールできるはずです。そうでない場合は、旧インストール方法をそのままお使いいただけます。
なぜ、このような良い知らせがあるのでしょうか。PowerShellの知識が1つのOSに限定されることがなくなるからです。バッチスクリプトはWindows上でしか実行できない(LinuxではWine経由で実行できるが、これはお勧めしない)ので限界があり、PowerShellで専門性を高めることができるようになった。
信じられるか?そうでない場合は、それでよいのです。先ほども言いましたが、PowerShellは万人向けではないので、個人で使う分にはバッチスクリプトでも構わないという方はご自由にお使いください。しかし、進化する技術を極め続けたい、ITプロフェッショナルの資格を取りたいと思うのであれば、PowerShellの習得は「if」よりも「time」が重要です。
もし、これから始めるのであれば、簡単で分かりやすいPowerShellの基本コマンドから始めましょう。これらをマスターしたら、PowerShellを使って自動化できる作業に移り、PowerShellのエラー処理方法を学びます。これだけあれば十分でしょう。