PowerShell は今や本当に優れていますが、ほとんどの Linux ユーザーはそれを認めません

James Mitchell included in Windows Powershell Microsoft Windows 11 Bash

2026-04-21 221 words 2 minutes

Contents

<本文>

長い間、Linux 界隈の暗黙のルールは、PowerShell は Windows のものであり、Bash が本物であるというものでした。私も当初はこの立場を維持していました。PowerShell の初期のイテレーションは使いにくく、Windows 専用であり、広く選択されて使用されていなかったからです。このバージョンの PowerShell はもう何年も存在していませんが、Linux コミュニティは、その進歩にもかかわらず、依然としてそれを無視しているという評判があります。

PowerShell は 10 年前からオープンソースでクロスプラットフォームになっています。 Linux と macOS の両方のネイティブビルドも用意されているため、Windows 専用の管理ツールではなくなりました。以前は、PowerShell 用のスクリプトを作成するたびに開く必要があるターミナルだと考えていましたが、その後は深く考えずに閉じていました。実際のプロジェクトで PowerShell を使用してみると、それはもはや書き留めるべきものではないことに気づきました。

すべての Windows ユーザーが知っておくべき 5 つの PowerShell スクリプト

PowerShell でできることはたくさんあります

PowerShell のオブジェクトパイプラインのスクリプト変更

Bash はすべてを文字列として扱うという制限があります

PowerShell が Bash と大きく異なる理由を理解するのに、認めたいよりも時間がかかりました。 PowerShell のパイプオブジェクトと Bash のパイプ文字列という 2 つの根本的な違いに気づいたとき、ようやくピンと来たのです。 Bash では、すべてのコマンドがテキストを出力します。その後、そのテキストを操作して有用なものにする方法を見つけます。これには通常、たとえ比較的単純なタスクであっても、生の出力を解析するために grep、sed、および awk への多くのパイプが必要になります。これらのツールは強力で、私は今でも常に使用していますが、PowerShell を使用すると多くのことが簡単になることは認めざるを得ません。

私の主張を説明する簡単な例を次に示します。この PowerShell パイプラインは、CPU 使用率によってプロセスをフィルターし、その名前を選択します。 CPU 使用率が 10% を超えると、出力として表示されます。


Get-Process | Where-Object CPU -gt 10 | Select-Object Name

ここで、同等のものを Bash で記述する方法を次に示します。


ps -eo comm,pcpu | awk '$2 > 10 {print $1}'

その違いは、読みやすさだけでもすぐにわかります。ただし、PowerShell は後続の各コマンドに単なるテキストではなくオブジェクトをパイプするため、この処理はさらに深く実行されます。 Bash は awk を使用して必要な列を分離し、プロセスが 10% 以上の CPU を使用するようにしています。これは基本的な例にすぎませんが、より複雑な Bash スクリプトとパイプラインは awk と sed を多用しており、コマンドが期待するものからまったく逸脱した形式で出力を渡すと壊れます。

上の例のような短いワンライナーの場合、日常的なタスクでは違いはそれほど重要ではありません。真の成果は、条件分岐、エラー処理、データ変換などの実際のロジックを備えた長いスクリプトにあります。ここでオブジェクトモデルが優れています。私の PowerShell スクリプトのほとんどは、同等の Bash スクリプトよりも大幅に短いだけでなく、数か月後に再訪するのもはるかに簡単です。しばらく触っていなかった Bash スクリプトでは、パイプラインを調べてデータの操作方法を思い出すのに少なくとも数分かかります。

Bash は移植性において依然として優れています

私自身のマシンでは、その利点は失われます

Bash はまさにどこにでも存在しますが、どこにも行くことはありません。これは SSH で接続するすべての Linux システムで見つかり、すべての Docker コンテナーでおなじみの Bash プロンプトが表示されます。さらに、Bash で書かれたスクリプトは、ほぼすべての Unix 系システムに移植でき、変更を加えることなく動作します。 PowerShell はクロスプラットフォームではありますが、そのレベルの汎用性には到達できないため、実際に期待できるのは、Windows マシンおよび自分が制御するその他のマシン上でのみです。

私は最初、ls の代わりに Get-ChildItem を使用したり、cd の代わりに Set-Location を使用したりするなど、動詞と名詞の命名規則が好きではありませんでした。冗長に感じますが、エイリアスを使用して短縮しました。PowerShell に慣れていないユーザーでも、一目見ただけでほぼすべてのコマンドレットの意味を推測できるため、各コマンドの明瞭さを評価するようになりました。

PowerShell とスクリプトに関する洞察を得るためにニュースレターを購読してください

PowerShell、Bash、および関連するスクリプトツールについて詳しく説明したニュースレターを入手してください。対象範囲には、オブジェクトパイプラインの説明、クロスプラットフォームの考慮事項、コマンドの比較、現実世界のトレードオフを明確にする具体的な例が含まれます。

アップデートを取得する

購読すると、ニュースレターとマーケティング電子メールの受信に同意し、利用規約とプライバシーポリシーに同意したものとみなされます。いつでも購読を解除できます。

いずれにせよ、私が書いているスクリプトのほとんどは私自身のシステム用であるため、Bash の移植性の利点は、私の自宅の研究室、仮想プライベートサーバー、または日常のワークステーションではあまり重要ではありません。 PowerShell のクロスプラットフォームバージョンは、実行する各システムで同じように動作するため、複雑な Bash スクリプトでパイプラインが圧倒されるたびに、PowerShell に手を伸ばす傾向があります。

私の Windows システムに関して言えば、WSL を実行すると、ツールを切り替えることなく、同じセッションから Windows API と Linux ファイルパスにアクセスする 1 つの PowerShell スクリプトを作成できることになります。それは Bash では絶対にできないことです。また、エラー処理 (パイプラインで信頼性が低いことで知られる終了コードと set-e は別として) や資格情報管理 (SecureString) などに相当するネイティブ Bash もありません。これらの便利なものは、より長く複雑なスクリプトでは不可欠であると感じ始めており、PowerShell に手を伸ばす理由がまた 1 つ増えています。

PowerShell の評判を調整する時期が来ました

間違いなく、PowerShell は Bash に代わるものではありませんし、その必要もありません。しかし、特に Windows 環境やハイブリッド環境で本格的なスクリプト作業を行う人にとって、ツールキットとしての地位を獲得しています。オブジェクトパイプラインだけでも学習する価値があり、古い批判のほとんどは、他のオペレーティングシステムで利用できるネイティブビルドには当てはまりません。ほとんどの Linux ユーザーは、PowerShell の進化に驚くでしょう。それは、彼らが実際にわざわざ見ようとしたことがあるかどうかです。

*️⃣ 出典リンク:

PowerShell は Windows のものであり、スクリプトは PowerShell 用に書かれています。すべての Windows ユーザーが知っておくべき 5 つの PowerShell スクリプト、PowerShell が Bash と異なる点、本当のメリットは長いスクリプトにあります、、、、、、利用規約、プライバシーポリシー、私が書いているほとんどのスクリプトは WSL を実行しており、Bash を置き換えています。