PowerShell -Part 7

**デフォルトの名無しさん** · 2025/06/28(土) 01:00:11.07

昔数百万行の各個別コマンドをpowershellでスレッドプール実装して並列処理で捌いたことあったけどvscodeの拡張機能でのデバッグが無かったら諦めてたと思う
拡張機能のおかげで大分開発しやすくなった

**デフォルトの名無しさん** · 2025/06/28(土) 16:43:22.73

>>471
なぜマルチスレッドの実装にこだわってマルチプロセスにしなかったのか？

スレッドのコントロールは面倒くさい。
互いのスレッドが干渉し合わないなら、別のプロセスとして実装すべき。

**デフォルトの名無しさん** · 2025/06/30(月) 14:31:10.94

「Windows PowerShell 2.0」は非推奨、将来的に削除～Microsoftが改めて注意喚起
「Windows PowerShell 5.x」や「PowerShell 7.5」への移行を
https://forest.watch.impress.co.jp/docs/news/2026721.html

**デフォルトの名無しさん** · 2025/07/08(火) 11:07:44.40

>>397
batの方が重大なミスしそうなんですがそれは

**デフォルトの名無しさん** · 2025/07/08(火) 11:08:23.57

>>398
っぱpwsh on linuxよ

**デフォルトの名無しさん** · 2025/07/08(火) 11:16:15.29

>>474
よく読め

**デフォルトの名無しさん** · 2025/07/08(火) 11:16:26.31

>>466
何時までも4,5系に留まるってことは無いと思うけどね
実際2からアップグレードされてきた訳だし
.NET Frameworkとの差異は比較的大きいにせよ
>>473の件もあるしそのうちプリインされるだろCore版が
なお6か7かはたまたまだ見ぬ8かは知らんけど

**デフォルトの名無しさん** · 2025/07/09(水) 05:32:28.94

powershellの日本語ドキュメント、chatGPTに翻訳させたらもっとマトモにならんかなあ…

**デフォルトの名無しさん** · 2025/07/09(水) 05:34:55.69

6もしぱらくバグまみれだったし7もバグどんどん見つかっていったし、最新がプリイン入る事は無いと思うな
多分最新の1つ前の最終マイナーバージョン、すなわちもし今なら6の最終バージョンじゃね

**デフォルトの名無しさん** · 2025/07/09(水) 06:17:43.31

.NET Frameworkと違って.NET5以降がOSに同梱はないでしょ
MS的に推奨かは知らんが関連するライブラリを標準モジュール含めて全部同梱配布が.NET系アプリのスタンダードになってるし今は

だったらロードさせることのないdllをOS標準で入れる意味も無いし未来永劫Powershell6以降は来ないって半分諦めてるけどね

**デフォルトの名無しさん** · 2025/07/09(水) 17:36:33.28

本日はご多忙の中、協力関係者様にお集まりいただきありがとうございます。
powershellは無事5.1で完結いたしました。
powershell第一部・完
6以降はまた別のお話とさせていただきます。
こんな感じ

**デフォルトの名無しさん** · 2025/07/10(木) 00:21:06.24

ps1の1は当時はバージョン名の想定じゃなかったっけ

**デフォルトの名無しさん** · 2025/07/10(木) 07:27:18.57

>>482
バージョンを表しているのは間違いない
ただ言語のメジャーバージョンとファイルフォーマットの互換性を表すバージョンは必ずしも一致しないって扱いなので、もし次に拡張子が変わるときが来るなら.ps2になる
https://devblogs.microsoft.com/powershell/ctp-versioning/
Excelを例に取ると97、2007でそれぞれ内部形式が変わっていて、2007では拡張子も変わっているので、いうなれば.xlsxは.xl3に相当するイメージ（5.0以前は無視した場合）
.ps1は最初はバージョンごとに毎回数字を変えるつもりだったけどやめたって説が巷で主流だけど、コレは公式のソースが見つからなかった

**デフォルトの名無しさん** · 2025/07/10(木) 11:15:28.70

microsoftは妙に互換性にこだわるから
拡張子.ps1はpowershellがどんなバージョンになっても変わらないよ
今は拡張子に「バージョンの番号が含まれてます」っていう意味すら意味をなくしていて
ただ単に「.ps1はpowershellスクリプトの拡張子です」ってだけの意味でしかないから
今さら拡張子を新しくするメリットが無い

**デフォルトの名無しさん** · 2025/07/10(木) 11:20:06.12

>>484
と思ったけどバージョン5とそれ以降では互換性に問題のある事が多かったなw
そういう誤実行を防止する目的で拡張子を変えるメリットあるかなぁ

**デフォルトの名無しさん** · 2025/07/10(木) 11:55:28.72

もうexeにすればいいんじゃねえかな
powershellで作ったかどうかすら判らんし

**デフォルトの名無しさん** · 2025/07/11(金) 21:41:14.58

https://devblogs.microsoft.com/powershell/ctp-versioning/

PowerShell Scripts continue to use “.PS1”.

We will continue to pursue this approach until there is a major change in the CLR or .NET frameworks which force us to go side-by-side. It is at that point that we’ll go from .PS1 to .PS2 . Until then we will stay with .PS1 and everything that runs today will continue to run in new releases.

**デフォルトの名無しさん** · 2025/07/12(土) 15:57:57.17

記事の日付は2007年やぞ

**デフォルトの名無しさん** · 2025/07/14(月) 21:23:18.49

PowerShell6で拡張子を変えなかった時点で
この先も.ps1のままなのはほぼ確定だよね

**デフォルトの名無しさん** · 2025/07/15(火) 01:51:30.33

俺たちのJeffrey Snoverはもういない、いないんだ…

**デフォルトの名無しさん** · 2025/07/15(火) 14:43:34.46

コマンドプロンプト使ってる人はたくさんいるけど
powershell使ってる人ここ10年で一度も見たこと無い

**デフォルトの名無しさん** · 2025/07/15(火) 17:26:35.63

>>491
コンソール（の外観）のハナシ？

**デフォルトの名無しさん** · 2025/07/15(火) 17:58:06.00

俺も、以下の1行をバッチファイル内に記述して実行する程度の事しかやってないな。
↓
powershell.exe -command ("Write-EventLog -LogName Application -EntryType Information -Source 'WSH' -EventID 0 -Message '(%~f0)_Windows Updateの画面を起動します。'") && start "" ms-settings:windowsupdate

※注1：
Windows7以降で標準搭載されているPowerShell(バージョン2.0以降)で使用可能な「Write-EventLog」コマンドレットは、バージョン6.0以降には搭載されてない。
だがバージョン2.0～5.1いずれかとの互換性が保持されている環境(「$PSVersionTable」変数内の「PSCompatibleVersions」プロパティを参照すれば確認可能)では問題ない。

※注2：
「ms-settings:windowsupdate」コマンドはWindows10～11のみで使用可。

**デフォルトの名無しさん** · 2025/07/15(火) 17:58:26.26

Terminalに移行したら分からなくなっちゃったか

**デフォルトの名無しさん** · 2025/07/15(火) 18:07:10.16

気軽にスクリプト実行できないから使い道がない

**デフォルトの名無しさん** · 2025/07/15(火) 20:54:02.36

本気で言ってるのか

**デフォルトの名無しさん** · 2025/07/15(火) 21:58:24.95

弊社はIT企業じゃないし、勝手にPythonを入れたりするとたぶん怒られるので
Windowsに最初から入ってるPowerShellを便利に使ってました
たまに、起動用のbatファイルとPowerShellスクリプトをセットにして同僚に渡すこともありました

**デフォルトの名無しさん** · 2025/07/16(水) 08:58:08.06

いい加減ペイント３DみたいにPowerShellのアプローチは失敗でしたと認めちゃばいいのに(´・ω・`)

**デフォルトの名無しさん** · 2025/07/16(水) 12:43:16.16

もうログインスクリプトにも使われてるから
Windowsの終焉まで逃げ出せないよ

**デフォルトの名無しさん** · 2025/07/16(水) 22:06:02.34

PowerShellのどのアプローチが失敗なのか具体的に

**デフォルトの名無しさん** · 2025/07/16(水) 23:17:35.03

起動用のbatが必要になっちゃうってのがな
PowerShell単独では使いにくい

**デフォルトの名無しさん** · 2025/07/16(水) 23:57:41.77

ん？どういうこと？

**デフォルトの名無しさん** · 2025/07/17(木) 00:10:22.13

ダブルクリック実行できるようにするために手間がかかる

**デフォルトの名無しさん** · 2025/07/17(木) 00:22:02.88

正直言ってexecutionpolicyの初期値は大失敗だろうなぁ
結局.batか.cmd経由でダブルクリック起動できるんだからマジで無意味
ネットから落としたファイルはzoneidがあるから設定に関係なく警告でるんだし

あとcmdもPowershellもWindowsのオマケであることに価値があるのにPowershell5.1までしか同梱されてないし

**デフォルトの名無しさん** · 2025/07/17(木) 07:33:01.42

もう直接powershell.exeに関連付けしてる

**デフォルトの名無しさん** · 2025/07/17(木) 08:05:58.12

>>482
それはバージョン1として普及させただけ。

いまとなってはバージョンを表してはいない。

**デフォルトの名無しさん** · 2025/07/17(木) 08:06:51.20

>>486
それはWindowsしか知らない人間の発想

**デフォルトの名無しさん** · 2025/07/17(木) 08:08:24.36

>>491
Windowsはターミナルというアプリで統合された。

PowerShellはコマンドプロンプトも含めているので、あなたが気づいていないだけ。

**デフォルトの名無しさん** · 2025/07/17(木) 08:09:59.60

>>495
実行形式にする必要がない。UNIX、Linuxは実行形式ファイルを嫌う。

ブラックボックス化はやめろ！

**デフォルトの名無しさん** · 2025/07/17(木) 08:11:35.61

>>501
バッチファイルにする必要もないよ？
バッチファイルなどでラッピングするのはWindowsの使い方のひとつでしかない。

**デフォルトの名無しさん** · 2025/07/17(木) 09:38:35.80

>>506-510
全部元発言者を意図を読み取れてない馬鹿のレス
UNIX使いの印象を悪くするだけなのでやめてくれ

**デフォルトの名無しさん** · 2025/07/17(木) 12:08:51.21

powershellは小数点以下のバージョンアップでも毎回互換性を壊す
破壊的変更を入れてくるから普及させる気無いんじゃね

**デフォルトの名無しさん** · 2025/07/17(木) 12:30:14.69

実際、6以降は普及させる気無いと思うよ
Azure関連を中心にMS社内で使うために開発続けてるだけでしょ

**デフォルトの名無しさん** · 2025/07/17(木) 21:54:18.35

PowerShellが失敗作じゃないと困る人がいるのは分かった

**デフォルトの名無しさん** · 2025/07/17(木) 22:59:18.52

PowerShell自体の出来はともかく、6以降は周辺環境がね
PowerShellは.NETがWindowsの中核として位置付けられていた頃に設計されており、
システムワイドにインストールされた.NETに安定的に依存できることが大前提なのよ
知っての通りその前提は完全に覆されてしまい、存在意義を失おうとしている

**デフォルトの名無しさん** · 2025/07/18(金) 01:15:27.61

知っての通りどころか.net frameworkは今もWindowsと一蓮托生だけど
.netと.net frameworkを分けて書かないと意味不明な文章が出来上がる

**デフォルトの名無しさん** · 2025/07/18(金) 22:16:02.55

Windows以外で.Netで作られたアプリやサービスなんてあんの？

**デフォルトの名無しさん** · 2025/07/18(金) 22:17:51.22

pythonで良くない？駄目？

**デフォルトの名無しさん** · 2025/07/19(土) 02:03:44.93

pwsh.exe

**デフォルトの名無しさん** · 2025/07/19(土) 08:55:57.75

>>518
Pythonがそこまで言い言語だとは思わないので

**デフォルトの名無しさん** · 2025/07/19(土) 10:16:02.54

>>517
ゲームエンジンのUnity

**デフォルトの名無しさん** · 2025/07/19(土) 19:43:58.62

>>517
GitHub Actions

**デフォルトの名無しさん** · 2025/07/20(日) 10:33:30.33

>>515は、元はシステム全体でひとつの.NETフレームワークを使ってPowerShellをCOMに対するWSHポジにするつもりだった、という意味だろうけど
.NETフレームワーク自体最初から複数バージョンを共存させる設計になってるので、果たしてそのような構想はあったのだろうか

**デフォルトの名無しさん** · 2025/07/20(日) 11:36:14.91

>>523
5以前のPowerShellはサイドバイサイドに対応していないから、使用される.NET Frameworkは結局一つだけ

**デフォルトの名無しさん** · 2025/07/24(木) 02:44:32.63

>>523
> .NETフレームワーク自体最初から複数バージョンを共存させる設計になってるので、果たしてそのような構想はあったのだろうか
.net frameworkはそんな設計じゃないぞ…

**デフォルトの名無しさん** · 2025/07/24(木) 18:49:30.39

コマンドレットを作ったが中途半端で.NET Frameworkを呼び出せばいいということにしたが、これではPowerShellを作った意味がないとしてPowerShellを拡張していまの混乱状態に至る。

**デフォルトの名無しさん** · 2025/07/24(木) 20:21:14.09

PowerShell独自の構文や機能はいらん .Net実行できる部分だけでいい
C#Scriptがほしい

**デフォルトの名無しさん** · 2025/07/24(木) 21:28:50.84

C#コードを単一ファイルでスクリプトのように書ける言語機能が「.NET 10」でテスト中
従来のプロジェクトベースへの変換も簡単
https://forest.watch.impress.co.jp/docs/news/2018094.html

**デフォルトの名無しさん** · 2025/07/24(木) 22:28:33.22

powershellのAdd-Typeを使えばC#を実行出来るらしいが

**デフォルトの名無しさん** · 2025/07/26(土) 11:52:54.27

Add-TypeのC#は、Windows API使いたい時、局所的に処理速度を上げたい時によく使う。

**デフォルトの名無しさん** · 2025/07/26(土) 19:50:25.05

ぜんぜん分からないんですけどAdd-TypeでC#を書くのって
インテリセンスが効かなそうで、ちょっとしんどそうなんですけど
そうでもないんですか

**デフォルトの名無しさん** · 2025/07/26(土) 20:51:36.43

PowerShellで使う程度のものなら余裕でバイブコーディングでいけるからどうでもいい

**デフォルトの名無しさん** · 2025/07/26(土) 22:09:50.67

なるほど

**デフォルトの名無しさん** · 2025/07/27(日) 01:39:44.77

もっとc#に近い記法にしてほしかったのになんでそうならなかったんだろう
配列の宣言とかセミコロンがないとか

**デフォルトの名無しさん** · 2025/07/27(日) 05:42:54.86

クラスはほぼC#だけど

**デフォルトの名無しさん** · 2025/07/27(日) 08:16:33.47

PowerShellは名前の通りシェルだからな
単なるスクリプト言語が欲しいだけならWSH.NET的なものを作ってる

**デフォルトの名無しさん** · 2025/07/27(日) 09:15:11.85

今のMSだったらRustあたりで作ったWindows CLIで一通りの管理タスクを一貫したコマンド体系でやれるようにした上で、
スクリプトはbashでもPythonでも何でも好きなの使えみたいにしてるだろうね
今となってはPowerShellはバルマー時代の古き悪きMSを象徴する遺産の一つ

**デフォルトの名無しさん** · 2025/07/28(月) 09:16:16.29

最初はbashの採用を検討してたけどWindowsには向かないって分かったからわざわざPowerShellを作ったんだが

https://x.com/jsnover/status/976904848162435072

**デフォルトの名無しさん** · 2025/07/28(月) 10:39:54.16

>>538
その理由はファイル指向のUNIXと違ってWindowsはAPI指向だからとJeffreyは述べてるんだけど、
一方でUNIX的なシェルで扱うのに適したCLIコマンドを整備するという方向もありえて、
実際MSがPowerShellにベットする以前はWMICのようにラッパーとしてCLIコマンドを整備していく方針だったんだよ
ただ、その方向で進む限りWindows上でのコマンドラインシェルは特殊なラッパーに依存することになり、決してWindowsスタックにおける主流になり得ない
そこで当時Windowsの新たな中核技術として喧伝されていた.NETプラットフォームに乗ることで、
MS社内にサービスしつつ一気にWindowsでのコマンドラインシェルを主流に押し上げようとしたわけだね
で現状はというと、肝心の.NETが主流から外されちゃって、PowerShellは一般のアプリの一つになっちゃいました(いまここ

**デフォルトの名無しさん** · 2025/07/28(月) 11:02:51.49

あと、現状について周辺の情勢も踏まえると、CLIを使ってAPI指向のプラットフォームを管理するスタイルはPowerShell 初期開発の当時と比較して遥かに市民権を得ているといえる
それはひとえにクラウドによるもので、現在ではクラウドプラットフォームのAPIをCLIを使って操作することは普通に行われており、しかもその多くはJeffreyの懸念に反して旧来のUNIXシェルを使用している
この現状を踏まえて今Windowsのコマンドライン管理を再考するとすれば、PowerShellのようなものが生まれる可能性は低いといえる

**デフォルトの名無しさん** · 2025/07/28(月) 17:29:52.01

Windowsは(少なくともOLE～.NET全盛期の頃のWindowsは)APIもオブジェクト指向する方向性だったので
それを操作するスクリプト言語もCOMオブジェクトや.NETオブジェクトを長期保持できなければいけない
単発で終了するCLIコマンドを揃えてもだめだろう

**デフォルトの名無しさん** · 2025/07/28(月) 19:14:24.95

おっさんエンジニアが全然使わないから無理だわ

**デフォルトの名無しさん** · 2025/07/28(月) 19:32:06.85

>>528
それだとVBScriptの二の舞

**デフォルトの名無しさん** · 2025/07/28(月) 19:33:30.80

>>534
そこがマイクロソフトの変なところ
いろんなプログラミング言語を研究して最良のものを作ったというのが当初の売り文句だった

**デフォルトの名無しさん** · 2025/07/28(月) 19:34:24.66

>>538
それはプライドが許さなかっただけ

**デフォルトの名無しさん** · 2025/07/28(月) 19:35:04.74

>>538
グーグルおじさんじゃねえか

**デフォルトの名無しさん** · 2025/07/28(月) 19:37:29.63

>>541
WindowsはWindows SDK開発がC言語でもC++でもいいというところから始まったせいで、形だけオブジェクト指向のC++が基本になってしまった。

**デフォルトの名無しさん** · 2025/07/28(月) 20:23:32.91

後発だからいろんな言語を参考にできるという強みがある一方で
Windowsのシェルスクリプトという世界最大級のしがらみのもと
あらゆるステークホルダーが全方位から好き勝手なことを言い
無数の歴史的経緯を踏まえつつデザインしないといけない無理ゲーなプロジェクト
変なクセが多い言語だけど苦労が偲ばれるからあまり文句を言う気にはなれない

**デフォルトの名無しさん** · 2025/07/28(月) 20:35:24.51

CとB-Shellが混じったような半端な記法

**デフォルトの名無しさん** · 2025/07/28(月) 21:11:45.32

今なら普通にTypeScriptになるだろうね

**デフォルトの名無しさん** · 2025/07/28(月) 21:57:11.64

bat埋込み技法とAdd-Typeでcsスクリプト化したった
スクリプトのくせに起動が遅いのが不満

**デフォルトの名無しさん** · 2025/07/29(火) 08:49:01.81

パイプにバイナリが流せるようになったPowerShell 7.4 からは使える子になった

**デフォルトの名無しさん** · 2025/07/29(火) 12:01:37.45

VBSもなんやかんや生き続けると思ったけどOSとしてサポート終了となれば話しは別やな

**デフォルトの名無しさん** · 2025/07/29(火) 14:11:31.33

>>552
パイプにバイナリ通せるつって1バイトずつbyteで送られてきても困るんだが
実際のとこどうなっとんの

**デフォルトの名無しさん** · 2025/07/29(火) 17:07:26.34

コマンド間にControl-Streamかまして調整する

**デフォルトの名無しさん** · 2025/07/29(火) 21:53:14.21

>>550
.NET対応のスクリプト言語なら静的型付けなJScript.NETが前からあるんだから
TypeScriptなんて中途半端な言語はいらない

Introducing JScript .NET
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/scripting-articles/ms974588(v=msdn.10)

**デフォルトの名無しさん** · 2025/07/31(木) 08:21:16.74

Windows PowerShell って

python3 -c 'print("hoge")'

とか

curl なんちゃら | tar かんちゃら

すらできないのに cmd.ехе にとってかわろうなんて無理筋にもほどがある
この辺だけでも PowerShell から持ってくればいいのに

**デフォルトの名無しさん** · 2025/07/31(木) 11:23:28.67

もう諦めてWSLでbash使えばいい

**デフォルトの名無しさん** · 2025/07/31(木) 13:18:34.83

>>557
互換性が無いのにデフォルトのAliasでcurlがInvoke-Webrequestになってるの酷い

**デフォルトの名無しさん** · 2025/07/31(木) 22:32:58.67

bashでは駄目だからわざわざPowerShellを作ったのにbash使えばいいとか意味不明すぎ

**デフォルトの名無しさん** · 2025/08/01(金) 00:05:22.62

curlがエイリアスって件だけは俺も擁護できない
あの罠は誰もが一度は引っかかる

**デフォルトの名無しさん** · 2025/08/01(金) 07:56:40.22

>>560
PowerShellはWindowsの管理のために作られたもので、その用途においてbashは不向きだといっているのであり、
君が示したようなWindows管理と無関係なケースでbashより推奨されているわけではない
加えて現在ではWSLという完全なUNIX環境がWindows上でシームレスに使用できるのだから、もはやPowerShellの役割は上記の通り極めて限定的になっている
一点だけ汎用シェルとしてのPowerShellの特徴として構造化データに強いというのがあるが、それだけならNushellとかの方が遥かに使いやすいよ

**デフォルトの名無しさん** · 2025/08/01(金) 08:52:42.59

・ >>557 の二つの例は PowerShell では問題なく実行できる
・ Windows のデフォルトコマンドラインシェルは Windows PowerShell

過去のしがらみで PowerShell をデフォルトにできないなら
Windows PowwerShell に >>557 が実行できるように機能追加するべき
Experimental feature として必要に応じで Enable できるように

とにかく今の Windows PowerShell がデフォルトってのが最悪

**デフォルトの名無しさん** · 2025/08/01(金) 09:31:11.55

・一部の人は「PowerShell」と「Windows PowerShell」を分けて考えている
バックポートしろって話ならできるのでは
公式がやるかどうかはともかく

**デフォルトの名無しさん** · 2025/08/03(日) 20:29:44.07

C#と同じでWindowsだけのものはバージョンが古いものだけ

単にPowerShellと呼んでいるのは、WindowsとLinuxとMacOSで動く製品だからだ。

**デフォルトの名無しさん** · 2025/08/13(水) 10:09:50.25

>>562
wslでpwsh使おうって方向性じゃないの？
chshするとwinとシームレスで快適だぞ
別にchshしなくてもホストのwin上リモートで繋げるしwslとの相性バツグン

**デフォルトの名無しさん** · 2025/08/13(水) 14:33:52.76

PowerShell 2.0 removal from Windows
https://support.microsoft.com/en-us/help/5065506

PowerShell 2.0 will be removed in a later release starting in August 2025 for Windows 11, version 24H2 and a September 2025 release for Windows Server 2025. All later releases for Windows 11 and Windows Server 2025 will not include PowerShell 2.0.

**デフォルトの名無しさん** · 2025/08/13(水) 16:04:08.55

.NET 10では「dotnet run」で.csファイルをそのままスクリプトとして実行できるようになるっぽい（要.NET SDK）
実行時にビルトされる点はこれまでと変化ないけど、ビルド成果物が一時フォルダに吐かれる？のか、.csファイルの場所が散らかることがなくなってスクリプト的に扱えるように

実行時のオーバーヘッドは...PowerShellと大差ない模様

**デフォルトの名無しさん** · 2025/08/13(水) 18:30:43.34

Pythonを検索してもファイルが見つかりませんとなります。
誰かどうすればいいか分かりますか？

**デフォルトの名無しさん** · 2025/08/14(木) 00:36:43.33

日本語でおk

**デフォルトの名無しさん** · 2025/08/14(木) 07:06:36.79

7をインストールしたけどエラー吐く時に黒背景に赤文字ってどうにかならん？くっそ見にくい

**デフォルトの名無しさん** · 2025/08/14(木) 09:27:10.03

じゃあそれ夏休みの宿題な

**デフォルトの名無しさん** · 2025/08/14(木) 09:54:56.24

$PSStyle.Formatting.Errorを変更する

about_ANSI_Terminals
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_ansi_terminals

**デフォルトの名無しさん** · 2025/08/14(木) 18:59:18.68

厨二シェル

**デフォルトの名無しさん** · 2025/08/15(金) 21:38:08.69

UNIXシェルが？

**デフォルトの名無しさん** · 2025/08/17(日) 04:08:48.96

powershellってコマンドがいちいち長ったらしくて打つのダルいんだよな
shellみたいに2文字3文字の略称で何の意味かわからんコマンドも学習するのに困るけど

**デフォルトの名無しさん** · 2025/08/17(日) 05:22:57.26

それな

**デフォルトの名無しさん** · 2025/08/17(日) 12:37:42.26

PowerShellのAdd-Typeでc#が書けるとよろこんだもののpowershell.exeの起動がクソ遅くcscでコンパイルする方が速い
なにやってんのコレ

**デフォルトの名無しさん** · 2025/08/17(日) 13:12:08.30

エイリアス使え

**デフォルトの名無しさん** · 2025/08/17(日) 13:29:34.64

ps1ファイルって暗号化とまでは行かなくとも難読化くらいはできねーの？

**デフォルトの名無しさん** · 2025/08/17(日) 15:36:02.04

正規表現の検索パターン内で変数配列を使いたいが角括弧のせいで動かない
エスケープの方法を教えてほしい

行末に一致させたいとして
-Pattern "$aryr[5]$" #ng
-Pattern "$arry`[5`]$" #ng
-Pattern "$aryr\[5\]$" #ng
-Pattern ($arry[5] + "$") #ok 美しくない

**デフォルトの名無しさん** · 2025/08/17(日) 16:37:39.55

コレじゃダメなんだっけ？

"$($arry[5])$"

**デフォルトの名無しさん** · 2025/08/17(日) 20:58:20.47

>>582
動いた
ありがとう！

**デフォルトの名無しさん** · 2025/08/17(日) 21:28:17.56

>>578
DLL化してPowerShelllで読み込む

PowerShell使わずに済むならC#だけでもいいと思うけど

**デフォルトの名無しさん** · 2025/08/18(月) 19:07:51.36

これが好み
'{0}$' -f $array[5]

**デフォルトの名無しさん** · 2025/08/18(月) 20:04:20.41

キモい記法だな

**デフォルトの名無しさん** · 2025/08/18(月) 21:29:02.39

-gt -ge -lt -leが覚えられないんだが
なんでこんなクソ記法にしたん？

**デフォルトの名無しさん** · 2025/08/18(月) 21:38:20.35

UNIXのshの記法だよ
どうせ非互換なんだからそんなとこだけ合わせんでもいいのにな

ちな実際に使われてるbashやzshでは拡張構文があるのでそんな書き方はしなくていい

**デフォルトの名無しさん** · 2025/08/18(月) 21:49:57.69

gt → greater than
ge → greater than equal
lt → less than
le → less than equal
覚えられないことは無いだろ

**デフォルトの名無しさん** · 2025/08/18(月) 22:27:56.29

shは条件判定が外部コマンド( /usr/bin/[ )になってるからリダイレクトで使う不等号を使えなかったんかな

**デフォルトの名無しさん** · 2025/08/18(月) 23:44:31.03

リダイレクト記号の > が大なりと判定されたらされたでキレる奴はたくさんいるし、文脈で判断すると難しいと不満を漏らす
gt や lt は天下のHTMLやXMLでもお馴染みだし ge も含めて ALGOL や Fortrun の時代からあるらしいから由緒ある演算子サマだ

**デフォルトの名無しさん** · 2025/08/19(火) 00:24:31.91

コマンドのワンライナーでも動かないとダメだしパイプやリダイレクトとも共存しないとダメってなると文法自体が分かりづらくなるのはやむなし
c#のスクリプト版みたいに思われてるけど本来そういうものじゃない

**デフォルトの名無しさん** · 2025/08/19(火) 19:46:40.89

>>589
やめてやれよ！

**デフォルトの名無しさん** · 2025/08/20(水) 07:51:25.99

結論　コマンドプロンプトでいい

**デフォルトの名無しさん** · 2025/08/20(水) 09:46:38.94

コード書くにはメモ帳で十分みたいなこと言うね

**デフォルトの名無しさん** · 2025/08/20(水) 11:21:33.79

老人は新しいことを覚えるよりも古い道具のハック含めていろいろ知ってるからね

**デフォルトの名無しさん** · 2025/08/20(水) 11:56:14.66

こういう立ち止まってくれる人達がいるから相対的に新しい技術にキャッチアップする若者がひきたつんだよな
感謝です

**デフォルトの名無しさん** · 2025/08/20(水) 13:09:09.63

立ち止まって深掘りするのもいいけど、立ち止まるなら立ち止まる土地を間違えないことが大事
10年前からWindows Serverの設定職人として立ち止まった人とAWS職人として立ち止まった人なら、同じ苦労をしても圧倒的に後者の方が現在の価値は高いわけで

**デフォルトの名無しさん** · 2025/09/05(金) 00:20:11.88

同じプロジェクトで未だにスクリプトをbatで頑張るおじさんがいてキツイ

**デフォルトの名無しさん** · 2025/09/05(金) 08:27:44.85

batなんかどうせ大して複雑なことできないんだから実害はほとんどない
むしろPowerShellで何でもやろうとするおじさんのほうが潜在的には問題になりやすい
というかbatおじさんが現役で活躍できるような職場でPowerShellやってんならお前も側から見りゃ大差ないから嫌ならさっさと転職しろ

**デフォルトの名無しさん** · 2025/09/05(金) 12:35:07.92

まあbatというかcmdのほうがド安定だよな
PowerShellはバージョンアップで動作が変わったりするので書いた本人がいなくなったあと困るんじゃないか

**デフォルトの名無しさん** · 2025/09/05(金) 13:24:51.33

AIがあるから困らない

**デフォルトの名無しさん** · 2025/09/05(金) 15:17:33.01

batおじさんワラワラ湧いてて草

**デフォルトの名無しさん** · 2025/09/05(金) 22:20:18.61

batの弱点は特殊文字のエスケープ処理がバラバラだったりそもそもエスケープできなかったり

**デフォルトの名無しさん** · 2025/09/05(金) 22:29:13.57

>>604
昭和50年代のパソコン向けに作ったものに文句を言うな！

**デフォルトの名無しさん** · 2025/09/05(金) 23:27:31.40

cmdの方が優れてるよ

**デフォルトの名無しさん** · 2025/09/06(土) 04:14:29.73

batが現役なの？
ヤバw

**デフォルトの名無しさん** · 2025/09/06(土) 08:28:06.76

.batと.cmdの違いがいまだに分からん
わざわざ新しい拡張子を作るなら分かりやすい構文でも導入すればよかったのに
このスレで言う事じゃないけど

**デフォルトの名無しさん** · 2025/09/06(土) 08:32:48.89

>>470
今更だが、環境変数PSModulePathの並び順で旧ver用を下にしたら直った

**デフォルトの名無しさん** · 2025/09/06(土) 13:36:28.33

>>594で結論出てるじゃん

**デフォルトの名無しさん** · 2025/09/07(日) 09:38:44.50

HTMLのリンク先がリダイレクトされる場合、自動でそのリダイレクト先のURLを取得するにはどのような方法がいいでしょうか？
$response = Invoke-WebRequest -Uri 壊れたリンク -MaximumRedirection 5 -ErrorAction SilentlyContinue
$location = $response.Headers['Location']
を試しているのですが、リダイレクト先のURLは取得できませんでした。

HTMLのリンク先は下記のとおりに取得してます。
$srcHtml = Invoke-WebRequest $url -UseBasicParsing
$html = New-Object -ComObject "HTMLFile"
$img = $html.getElementById("img").getAttribute("src")

**デフォルトの名無しさん** · 2025/09/07(日) 21:42:00.61

-MaximumRedirection の値を5から0に変える

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.utility/invoke-webrequest#-maximumredirection

-MaximumRedirection
接続が失敗するまでに、PowerShell が代替 Uniform Resource Identifier (URI) に接続をリダイレクトする回数を指定します。既定値は 5 です。値が 0 (ゼロ) の場合、すべてのリダイレクトが禁止されます。

**デフォルトの名無しさん** · 2025/09/11(木) 20:02:03.10

V7.4.12とV7.5.3が出ました。

**デフォルトの名無しさん** · 2025/09/12(金) 08:06:46.54

マジカルちんぽの持ち主になりたい

**デフォルトの名無しさん** · 2025/09/13(土) 09:54:11.18

俺も！

**デフォルトの名無しさん** · 2025/10/03(金) 00:50:10.33

transcriptってログ取るのにめちゃくちゃ便利ですね
今までログ出力ゴリゴリ書いちゃってたけどもっと早く知りたかった

**デフォルトの名無しさん** · 2025/10/03(金) 09:18:17.43

bashだったらscriptコマンドで苦労しなかったのに

**デフォルトの名無しさん** · 2025/10/04(土) 15:26:39.76

そう思う人が何でこのスレに来るの？
一人で勝手にbashでオナニーしてればいいだけでしょ

**デフォルトの名無しさん** · 2025/10/04(土) 21:22:40.46

まぁまぁそんないじめなさんな

**デフォルトの名無しさん** · 2025/10/12(日) 01:42:26.66

scriptとか使わんでも
たぶん標準、だったかな？
でpsのセッションはすべて保存されてるとおもうが…

**デフォルトの名無しさん** · 2025/10/12(日) 01:55:12.70

ごめん今$profileみたらStart-Transcriptを自動で呼ぶようにしてて、標準ではたぶんアクティベートはされてないわ
Start-Transcriptコマンドレットが>>617のいうtclのscript(b系shで代わりによく使われるヤツ)の上位互換だよ

tclのscriptやpwshのStart-Transcriptは普段から使っておくべき
ログが膨れ上がるから、無駄なタイプアウトを控える良い癖がつく、すなわち後から振り返り難くないよう、セッションのログを汚さないようにとslsやページャに頼るようになるということだ

**デフォルトの名無しさん** · 2025/10/12(日) 02:00:35.65

transcriptしてれば、脳死gci連打したりと恥ずかしい思いを避けるように、毎回熟慮したスマートなコマンドを構築しようとスキルアップへ向かえるわけですよ
オススメ

**デフォルトの名無しさん** · 2025/10/14(火) 10:05:34.66

困ってます。ps1をショートカットで簡単に開けなくなりました。
Powershellを楽に実行してもらうには
https://qiita.com/tomoko523/items/df8e384d32a377381ef9
↑これを参考にして、
ps1ファイルのショートカットを作って、プロパティのリンクに、
powershell -ExecutionPolicy RemoteSigned -File
という文字列を最初にをつけるというのをやりました。

powershell -ExecutionPolicy RemoteSigned -File C:\Users\User\Desktop\test.ps1
みたいな感じになる。
それでショートカットのダブルクリックでps1ファイルが開けてた。

でも、しばらくすると、新しくショートカット作ったらダブルクリックでできなくなった
というか、ショートカットのリンクに
powershell -ExecutionPolicy RemoteSigned -Fileの文字列を貼り付けたら、okを押せなくなった。
エラーメッセージが出て。
で、前に作ったやつはダブルクリックでできたので、それを開いて確認したら、
powershell -ExecutionPolicy RemoteSigned -Fileの
powershellの部分が
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
に勝手に書き換わってた。

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-ExecutionPolicy RemoteSigned -File C:\Users\User\Desktop\test.ps1　みたいな感じ

たぶん、できなくなる前後くらいに、windows powershell v5.xしかなかった環境に
powershell v7.xをインストールしたからだと思う
powershellって文字列で、自動でwindows powershell v5と連携できてたのが、
powershell v7を入れたせいで、環境変数？とかが変わったのか、よくわからないけど
自動で連携できなくなったのかな。
で、前のやつは、いつのタイミングか、powershellの文字列が、windows p.s. v5へのパスに変わってたんだと思う。
powershell の文字列で、ショートカットのリンクに文字列入れてやる方法ないでしょうか？

**623** · 2025/10/14(火) 10:13:14.09

[Window Title]
ショートカットエラー

[Content]
受け側に指定されたパス名 'powershell' は無効です。パスとファイル名が正しいか確認してください。

↑
エラーメッセージはこれです
でも、はじめはps1のショートカットで
リンクの文字列を追加するときは
powershell～だけで
powershellへのフルパスがなくてもok押せて、ダブルクリックで起動できてたんですよね

なにかpowershellの文字列だけで
v5やv7を自動で起動できるように設定する方法とかわからないでしょうか？

**デフォルトの名無しさん** · 2025/10/14(火) 10:46:54.11

powershell7を入れるとpowershell5とは違うパスにインストールされて
powershell => v5
pwsh => v7
という具合に使い分けができる
powershellが呼べないなら
そのパスにpowershell.exeが無いのかもしれない
> 受け側に指定されたパス名 'powershell' は無効です。
というエラーがそれを裏付けてると思う
まずはv5の本体があることを確認するべき
バージョンアップした感覚で
自分で「古いv5はいらないからアンインストールしちゃお」としてるかもねw

**デフォルトの名無しさん** · 2025/10/18(土) 01:00:25.12

>>623
>powershellの部分が
>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
>に勝手に書き換わってた。
これは正しい動作

現在、動くショートカットが有るならば、v5は消されていない
ps1ファイルのショートカットを作成した直後ののアイコンと
プロパティに「powershell以下略」を追記したショートカットでは
アイコンが変化する。変化してるならリンクは正しい

正常動作するショートカットのリンク先をコピーしてメモ帳に張り付けて
新しく作りたいリンク先を見比べながら書いたらどう？

**デフォルトの名無しさん** · 2025/10/20(月) 16:54:33.98

ショートカットの文法はcmdともなんか違ってて謎が謎を呼ぶ闇

**デフォルトの名無しさん** · 2025/10/21(火) 05:46:20.22

Z7.4.13とV7.5.4出ました。
https://github.com/PowerShell/PowerShell/releases/tag/v7.4.1
https://github.com/PowerShell/PowerShell/releases/tag/v7.5.4

**デフォルトの名無しさん** · 2025/10/21(火) 05:46:43.72

7.4.13
https://github.com/PowerShell/PowerShell/releases/tag/v7.4.13

**デフォルトの名無しさん** · 2025/10/21(火) 22:17:43.72

ショートカットの文法ってのがコマンドラインパラメータの事を言ってるなら
別プログラムなんだからcmdと違っても普通でしょ？　何が謎なの？

**デフォルトの名無しさん** · 2025/10/27(月) 23:10:58.60

自分も似たようなこと（カスタムURLスキーム経由で登録済みバイナリにメッセージを送信）をしてたけど、これはかなり丁寧にパッケージングされてる
GitHub - Fred-Vatin/run-yt-dlp-from-browser: Run yt-dlp commands from any browsers
https://github.com/Fred-Vatin/run-yt-dlp-from-browser

**デフォルトの名無しさん** · 2025/11/01(土) 07:47:46.11

何もしてないけど PowerShell v7.5.4 が WindowsUpdate で降ってきた
履歴ちゃんとみたらいつまにか PowerShell って WindowsUpdate で降ってくるようになってたわ

**デフォルトの名無しさん** · 2025/11/02(日) 18:28:28.27

バナーで更新通知見かけてもwinget updateで更新できなくてそのうちWindows Updateで更新されてる

**デフォルトの名無しさん** · 2025/11/02(日) 22:12:18.83

ターミナルでタブを移動しようとしたら消しちゃって泣きを見たのでタブを縦に並べられるtabbyを使ってる
地味に便利

**デフォルトの名無しさん** · 2025/11/04(火) 22:05:10.67

Tver のサイトで特定のドラマのページを開いたときに右上に表示されている最新話のURLを取得したいんですが知識がなくてさっぱり・・・
例えばちょっとだけエスパーの
https://tver.jp/series/srm706pd6g
で右上に表示されているエピソードを再生のURLをとりたいのですがソースを表示するとどこにもない

**デフォルトの名無しさん** · 2025/11/05(水) 00:15:01.45

このスレで聞くことか？

**デフォルトの名無しさん** · 2025/11/05(水) 00:19:16.72

PowerShellの質問ではないわな

**デフォルトの名無しさん** · 2025/11/05(水) 03:58:33.49

>>635
ソースで見ると表示されないのはJavaScriptで生成されてるからで、素のHTMLには書かれてないんだよ
ブラウザでエピソードを再生を右クリックして「検証」とか「調査」っていうメニューで確認できるよ
使っているブラウザのスレで開発ツールの使い方を教えてもらうか、ChatGPTに聞くのが分かりやすいと思う

ChatGPTにuserscriptを作ってもらうか、どうしてもPowershellでやりたいならapiを叩いたらどう？
ttps://pastebin.com/paBznTfW
これもChatGPTに教えてもらうと良いよ(↑のもChatGPTが作ってくれた)

**デフォルトの名無しさん** · 2025/11/05(水) 18:41:39.53

>>638
ありがとうございます！！！
もっと精進します

**デフォルトの名無しさん** · 2025/11/06(木) 20:55:27.46

PowerShell に関するお問い合わせ時の留意事項
https://jpwinsup.github.io/blog/2025/11/06/UserInterfaceAndApps/PowerShell/PowerShell-SupportGuidlines/

**デフォルトの名無しさん** · 2025/11/09(日) 01:50:45.56

>>640
>なお、 .NET Framework や Win32 API は、C#/VB#/C++/C といったプログラム言語からのご利用を目的として提供している機能になり、動作確認もこれらの言語で行っていただくことをお願いしております。
>また、これらの言語で正常に動作しながらも、PowerShell 上で期待通りの動作とならない場合は、プログラミング言語のご利用をお願いしておりますことをご留意ください。

あれれ?
PowerShellでたての頃って.netのオブジェクト使えるの売りにしてなかったかな?

**デフォルトの名無しさん** · 2025/11/09(日) 09:43:41.33

最近の.NETは言語非依存を放棄してるからな
例えばSpanはPowerShellから使えない

Question about System.Span
https://github.com/PowerShell/PowerShell/issues/5897

**デフォルトの名無しさん** · 2025/11/09(日) 10:23:37.05

.NET Frameworkって書いてあるからCore系の.NETは関係ないでしょ。Core系もサポートの方針は同じだろうけど。
PowerShell6以降のユーザーなんて5に比べりゃほとんどいないだろうし、
わざわざ6以降使ってる人はそんなに変な問い合わせしてこないだろうからサポート的にはあまり問題にならないんだろう

**デフォルトの名無しさん** · 2025/11/18(火) 00:02:06.52

c#14でファイルベースでスクリプトライクに書けるようになった
もうpowershellはオワコン！

**デフォルトの名無しさん** · 2025/11/18(火) 17:30:44.99

それパイプは直感的に書けるか？