みなさんはPowerShellをご存じですか？

VSCodeとかを使わずに、シェルスクリプトを書いてPowerShell上で実行できるPowerShell ISEというのがあります。

ほぼフォルダエクスプローラの代替として使用しています
どのシェルでも(コマンドプロンプト含む)基本的な用途は変わらないので、特別視したことはありません

C#とほぼ同感覚で型を扱える点は長所だと思いますが、フルパスをデフォルト表記してくれる点はcmd whereの方が優位ですし、フォルダ検索も別にForEach使う必要はないし...という感覚です

あと、自作関数もglobal:をつけないとデフォルトで読み込まないのが不便だなと
exportに代わる機能が分かりません

「あるいは知っていたとしても」が全てな気がするなぁw
ちょっとしたテキスト処理とかChatGPTのおかげでPowerShell使う機会は増えたけど、それでもWSL ubuntu立ち上げることが多い。

当方の経験上は、ガチガチの SES 現場等だと保守担当者であっても利用 PC に対して気軽にソフトウェアをインストールできないため、PowerShell 5.1 一択だったりしますね泣

サポート期限も長い方が好まれるのでさらにそうなりがちです。

AD, Exchange Server, Azure Automation, Microsoft Graph etc... MS 製品扱う上では優位性があるというかデファクトかと思います(当たり前ですが)。ので管理タスクや自動化開発など淡々と利用している感じです。

.NET (Framework) がベースにあるおかげで、いざとなるとかなりのことができるのが良いですね。今更 VBScript には戻りたくないかな。。。

function から配列返却したときに要素数が 1 つだと配列を解いてしまうワナに時々ハマって困ります笑

PowerShellはネットワーク上の他のWindowsホストに対して、適切な権限があれば、リモートホスト上での処理がしやすい印象がありますね。

@mu-MueLangDeveloper
コメントありがとうございます！

PowerShell ISEというのがあります

ISE、ありますね～
スクリプトの作成や実行・テストができて、シンタックスハイライトや補完機能も備えたIDEがデフォルトで使えるというのもPowerShellの特徴かもしれないですね。
まあ使い勝手が少し独特というか古い部分もあるので自分はもっぱらVSCode+拡張機能で開発しちゃてますが...

@blonz3977
コメントありがとうございます！

ほぼフォルダエクスプローラの代替として使用しています

スクリプトを書くことばかりに気を取られてましたがそういう使い方もありましたね...
たしかに、その用途だとどのシェルでも差はないですよね。

自作関数もglobal:をつけないとデフォルトで読み込まないのが不便だなと

こちらが少しわからなかったのですが、スクリプトを複数に分割してStart-Jobとか&で別プロセスで実行すると一方のスクリプトで定義した関数がもう一方から参照できない、みたいな話ですかね？
プロファイルに定義すればどこからでも使えるとは思うんですけど、それとは違う話ですかね？

@te2ji
コメントありがとうございます！

「あるいは知っていたとしても」が全てな気がするなぁw

想定回答を書きすぎましたかねw
ただ、やはりこの辺は同じことを思っている人もいるんだ～と安心しました。

ちょっとしたテキスト処理とかChatGPTのおかげで

自分も最近はPowerShellとChatGPTをセットで使うことが多いですね。
PowerShellは.NETの機能も使えるおかげでネット検索だと情報の選別が必要なところをChatGPTだと自分の用途に100%マッチしたコードを提案してくれるので「効率化のための処理をパパっと書きたいだけなのに実装に時間がかかる」というジレンマが解消されてきた感じがします。

@mako1047
コメントありがとうございます！

利用 PC に対して気軽にソフトウェアをインストールできないため、PowerShell 5.1 一択だったりしますね泣

自分もまさに似たような環境にいたことがあって、その時にPowerShellに目覚めましたw

MS 製品扱う上では優位性があるというかデファクトかと思います

AzureのCLIツールやコンソールもPowerShell版が充実してますもんね。（もちろんBash版も用意されていますけども）
あとMS製品関連でいうと、特に何もインストールしなくてもCOMオブジェクト経由でExcelを操作できる点もPowerShellの優位性かなと思ってます。(Windows限定ですけどね)

function から配列返却したときに要素数が 1 つだと配列を解いてしまうワナに時々ハマって困ります笑

これはまさに自分も何度も引っかかった点で、ちょうどこれをテーマに記事を書こうと思っていたところですw

@jinbei230525
コメントありがとうございます！

リモートホスト上での処理がしやすい印象がありますね

コメントをもらって初めて知ったのですがこちらのドキュメントにあるようなコマンドレットのことですかね？たしかに、ただリモート接続するだけでなく処理を行える点が魅力的ですね。
PowerShellはWindows自体の機能を呼び出すコマンドレットが充実しているのも特徴ですよね。（ジョブスケジューラ関連とか）

業務用PCや担当している組み込み製品がWindows10でPowerShellが動くため、自動テストや負荷テスト等に使用しています。実行ファイルがバイナリではないので負荷調整等の変更がその場で簡単にできます。

また、開発者以外に便利ツールを配布する際にも使用しています
PythonやGoだと開発者以外にプログラム配布する際に実行環境の用意からする必要があり面倒です。

Microsoftなのでスクリプトが陳腐化しにくいとも考えています。

プロファイルに定義すればどこからでも使えるとは思う

スコープ修飾子が必要らしく、一度嵌ったことがあります

スクリプトごとにスコープが異なっているため、ということでした
https://atmarkit.itmedia.co.jp/ait/spv/0709/20/news125_4.html

@pea1205
コメントありがとうございます！

実行ファイルがバイナリではないので負荷調整等の変更がその場で簡単にできます。

まさに自分も同じ意見で、前にPowerShellでテスト用のREST APIサーバーを立てたときもロジックやパラメータの書き換えが即時反映されるので動作確認がスムーズに進むというメリットがありました。

開発者以外に便利ツールを配布する際にも使用しています

ここも完全に自分の使い方と同じですｗ
もしかしたらpea1205さんも同じかもですが、自分の場合、ツール化するときはbatから呼ぶ形にしてダブルクリックで実行できるようにしてあげてます。

@blonz3977

スクリプトごとにスコープが異なっているため、ということでした

たしかに自分もスコープの範囲を誤認してエラーにはまった経験があります...
この辺はBashも同じだと思うんですけど、サブシェルとか子プロセスとスコープの関係・影響が他のプログラミング言語より顕著にでてくる印象です。

Windows 7の頃は無視していましたが、10から使い始めました。

httpからのファイルダウンロード、管理者権限での柔軟なプロセス実行、UNCパスの完全対応などはビルドインコマンドで対応できる点は良いと思います。頑張ればGUIも作成できます。
これらはバッチ標準では対応が難しく、たった数行ならPowerShellを使おうという気になれます。

独特の構文

VBScript、VBA、HTA、これらに比べたらまだマシな方です。

@STSynthe
コメントありがとうございます！

ビルドインではじめから使える点や数行だけでも色んな操作が行える点はポイント高いですよね。

VBScript、VBA、HTA、これらに比べたらまだマシな方です。

たしかにw
VBAは開発環境もひとくせありますよね。VSCodeで補完効かせてスムーズに開発できるなら候補に上がるんだけどな〜

Windowsにも古くからバッチ（ファイル）がありましたが、それよりも様々な機能をサポートすることで開発保守業務を助けるツールだと思っています。Windows標準のソフトウェアで実行権限に気を付れば、使う際に入手やインストールの手間がいらずハードルも高くないのかなと感じます。ただ、どういうときにこれを使うことで生産性が上がるよとか、そのために何が大切なのかとかが、よくわからず勉強中です。

ほかのshellと異なり、cmdと標準入出力が連携出来ないお粗末な実装のため、全く使う気にならないです。cmd (bat) の置き換えでもないみたいなので、存在理由が解らず。従来のcmdやMSYS bashなどの方が学ぶ価値もあると思ってます。

@masa555

コメントありがとうございます！

入手やインストールの手間がいらずハードルも高くないのかなと感じます。

このハードルの低さは特に開発保守関係の人には魅力的ですよね。

どういうときにこれを使うことで生産性が上がるよとか、そのために何が大切なのかとかが、よくわからず勉強中です。

ここは自分も常に勉強中です。
個人的に気をつけているのは「いろいろできるからといって何でもPowerShellでやらないようにする」ですかね。
素直にPythonとかJavaScriptとかシェルスクリプトを使う方が早い場合もありますし、やはりマイナー寄りの技術なので他の人にメンテさせにくいものだということは意識するようにしています。

@libraplanet

コメントありがとうございます！

cmd (bat) の置き換えでもないみたいなので

たしかにcmdにしか存在しないコマンドもありますもんね。
cmdにしかないコマンドはWindowsのよりコアな機能に触れられそうな印象があるのでちょっと興味ありですw

cmdと標準入出力が連携出来ない

ここはちょっと分からなかったのですが、以前にこちらの記事で以下のようにPowerShellからassocを呼んで標準出力される文字列を処理してftypeを実行したんですけど、こういう話ではなくですかね？

# 読み取り専用オプションの付与
cmd /c assoc | ? {
  # 一部の拡張子についてのみ変更（必要に応じて適宜追加）
  $_ -match '^\.(xlsx|xlsm|xls)='
} | % {
  # ファイルタイプに関連づくコマンドを取得
  cmd /c ftype $($_.Split('=')[1]) 2>$null
} | % {
  # 実行ファイルに /r オプションを付与
  cmd /c "ftype $( $_ -replace '"(.*excel.exe)" "%1"$', '${1} /r "%1"' )"
}

もしよければ後学のために、どういうことをしたかったけどできなかったというのを教えていただけたら嬉しいです。

職場はADのポリシーで制約付き言語モードになっているので、ほぼ使えない状態ですね（ダウングレード攻撃すれば動きますが、EDRに検知されて情シスに怒られそう…）。
BATやvbsの代わりとして共有しようにも、デフォではダブルクリックで起動しない上に、簡単な処理でもPowerShell自体の初回起動がやたら遅い（日本語環境だけ？）ので使い物にならない。
VBAのActiveXも無効化されるようだし、vbsもいつ無効化されるのか分からない。

マイクロソフトも色々無効化する前にデフォルトの環境で真っ当にバッチスクリプトが動くような環境を整備して欲しいものです。

@Cool0707

コメントありがとうございます！

ADのポリシーで制約付き言語モードになっている

実行ポリシーは知っていましたが言語モードというのもあったんですね。
こちらの記事を見るに使えるクラスがだいぶ制限されるみたいですね。だとすると確かにほぼ使えなさそう...

BATやvbsの代わりとして共有しようにも、デフォではダブルクリックで起動しない

ダブルクリック起動させようと思うとBATとかVBSとの組み合わせになってきますよね。
ちなみに自分はpowershellコマンドに引数でスクリプトブロックを渡すショートカットを作ってダブルクリックで実行できるようにしたことがあるんですけど、情シスにウイルス扱いされてPCを止められたことがありますｗ

VBAのActiveXも無効化されるようだし、vbsもいつ無効化されるのか分からない。

たしか廃止が決まってたようなと思って調べたら2027年にはデフォルトで無効になるみたいですね。
（もしそうなったら当面はVBSを有効化するPowerShellスクリプトが流行るかも？）

マイクロソフトも色々無効化する前にデフォルトの環境で真っ当にバッチスクリプトが動くような環境を整備して欲しいものです。

たしかに無効化するだけじゃなくて開発者向けの環境整備もしてほしいですよね。
諸々の無効化はライトユーザーには問題ないのかもですけど、開発者としては使いづらいOSになっていくな～という印象です。

@www-tacos

ダブルクリック起動させようと思うとBATとかVBSとの組み合わせになってきますよね。

こちらの記事のようにBATファイル一つにまとめる事もできますが、後で他人が見てもこれはBATファイルの中にPowerShellのコードが埋め込まれているんだな！って分からないと思うんですよね。

諸々の無効化はライトユーザーには問題ないのかもですけど、開発者としては使いづらいOSになっていくな～という印象です。

ライトユーザーでも素直な作りのバッチスクリプトなら、やる気さえあればChatGPT等に聞きながらメンテしたり新たに作れると思いますが、色々な規制を乗り越えるために凝った作りのスクリプトだと無理なんですよね。
そういう意味では日本企業の被管理ユーザーには優しくないOSですよね。

例えば、私の職場などでは、ソフトウェアの制限のポリシーの規則で%USERPROFILE%以下でexeを起動できないため勝手にソフトウェアを開発出来ない風になってます。
でも、%TEMP%以下では（ソフトウェアアップデート等に必要なため）exeを実行可能なので、.NET FW内のcscでソースコードをコンパイルすれば一応開発できますけど、そんな風にツール作って所属内で広めても、絶対誰もメンテ出来ませんからね…

最近PowerShellに入門した最初の感想としては、他の言語のキラキラした部分をひたすら詰め込んでるなぁという印象でした。
ちょうどGOLANGで言うところの｢退屈なGO｣とは対極の思想というんですかね。
どちらが良いとは言いませんが、自分一人だけで使う分には便利であるものの、第三者が絡む場合はあまり使いたくないですね。

@fue_tatsuya

コメントありがとうございます！

他の言語のキラキラした部分をひたすら詰め込んでるなぁという印象

パワー"シェル"と言ってますがシェルスクリプトより高級言語に近い言語ですよね。ベースにC#とか.NETの存在があるからかな？と思ってます。

自分一人だけで使う分には便利であるものの、第三者が絡む場合はあまり使いたくないですね。

使ってもらうだけならまだしも、第三者にメンテ・手直しさせるのは自分も気が引けちゃいます...できれば知ってもらいたい気持ちはあるんですけどね。

コマンドプロンプト&バッチファイル、Windows Script Host、Windows PowerShell、PowerShell 7 …と、全部使って来ております。
PowerShell は今までのものに比べてコマンド向けとスクリプト向けを併存させようとして混沌としてる印象がありますね。
プログラマとしてはC#やVB.NETくらいに型を扱ってくれたら、スクリプ書きやすくなる気がします。現状のPowerShell、割となんでもobject型にされがち…
逆にシェルとして使いたい人にはちょっと仕様が重すぎる気もします。

@kagilinn

コメントありがとうございます！

C#やVB.NETくらいに型を扱ってくれたら、スクリプ書きやすくなる気がします

激しく同意ですｗ
Pythonみたいに型が動的なせいだからか、VSCodeの拡張機能を使ってもプロパティやメンバの補完がたいして効かないのがツラいです...

逆にシェルとして使いたい人にはちょっと仕様が重すぎる気もします。

たしかに、たとえば pwd でもBashなら単に文字列で返ってくるところがPowerShellだと System.Management.Automation.PathInfo オブジェクトなので Path プロパティを見ないといけなかったりで簡潔ではないですよね。ワンライナーもすぐに2行目3行目に折り返してしまうな～という印象です。