PowerShell -Part 7 (556ﾚｽ)
上下前次1-新
1: 2023/11/29(水)16:07 ID:0g8RZ7sB(1) AAS
前スレ
PowerShell -Part 6
2chｽﾚ:tech
次スレは>>980が立ててね！！
430: 04/27(日)22:05 ID:aGrpQ/Rq(1) AAS
中身全部消すのであれば内側のKWは無視していいのでは
431(1): 04/27(日)22:11 ID:/1DxBHsK(2/2) AAS
簡単には
$text = DOCTYPE宣言を除いた<html>〜</html>とかXMLとして読み込めるテキストデータ
$xml = [xml] $text
while($node=$xml.SelectSingleNode("//div[@class='KW']")){
$null = $node.ParentNode.RemoveChild($node)
}
$xml.OuterXml | Out-File 〜〜〜
## class="aaa KW bbb"の存在とか、インデント等を完璧に維持したい、とかは考慮外。
432: 04/27(日)22:22 ID:/O0GUF2P(3/4) AAS
>>431
なるほど
こんな感じにしてたんだよ
$list=@()
$doc.GetElementsByTagName('div')|?{$_.class -eq "KW"}|%{$list+=$_}
$list|%{[void]$_.ParentNode.RemoveChild($_)}
433: 04/27(日)22:48 ID:/O0GUF2P(4/4) AAS
悩んでたのは
既に削除しちゃてて存在しない場合にエラー無視はやりたくないなあってところ
434(2): 05/02(金)21:45 ID:TuuGRLh6(1) AAS
powershellって日本語に厳しい？
日本語名のフォルダに入れた時だけエラー吐く
英語名フォルダは動く
UTF-8BOMで保存してるのに文字化けエラーが治らない
435: 05/02(金)22:24 ID:OrgxTXnx(1) AAS
いわゆる「マルチバイト文字」のことを「日本語」と呼ぶのはジジイ
436: 05/03(土)07:39 ID:ERFTsxnY(1) AAS
UTF-8にBOMは不要
437: 05/03(土)17:59 ID:0tHkB26n(1) AAS
文字コードが混在するシステムではBOMがあると便利です
438: 05/03(土)18:08 ID:qBega2UP(1) AAS
それが更に文字コードのバリエーションを増やし失敗を生むのだから本末転倒です
439: 05/03(土)18:08 ID:PV3Uf1QS(1) AAS
PowerShellスクリプトは「UTF-8 with BOM」が前提
>>434
実行時（コンソール）のコードページを確認してみては？
440: 05/04(日)07:07 ID:kiovYued(1) AAS
shift-jisにすればいいんじゃないの？
441: 05/04(日)08:23 ID:GZLENS5k(1) AAS
適切なエンコードの選択
外部ﾘﾝｸ:learn.microsoft.com
442: 05/04(日)11:02 ID:Bff2jlZm(1) AAS
文字化け対策は
[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
こういうのをpowershellのプロファイルに書き込んで
powershell起動時に文字エンコードが適切な値になるようにしておく
そしてコンソールのタイトルバーを右クリして設定で適切なフォントが使用されてるか確認
443(1): 05/09(金)16:18 ID:LImQScat(1) AAS
>>434 とは別人だが、レジストリ弄ったら文字化けしなくなったわ
初心者泣かせのクソ仕様だな
444(1): 05/10(土)10:47 ID:ARU6YZDD(1) AAS
>>443
powershellをアップデートしたらリセットされそうな予感
445: 05/10(土)15:03 ID:L74jL6NI(1) AAS
>>444
文字化けするようになったのはプロパティでコンソール画面の調整を行ってから
デフォルトの状態では文字化けしていなかったのでたぶん大丈夫…と思う
446: 05/18(日)16:44 ID:w/29XAyn(1) AAS
$a = powercfg.exe -lastwake
$aは文字列かと思ったら文字列の配列だった…
コマンドの出力に改行が無ければ文字列、含む場合は配列とかいうヘンテコ仕様は何なんだ
447: 05/18(日)19:51 ID:xRSUEbTb(1) AAS
この振る舞いを知らないと、$a.Lengthが時により文字列長だったり配列長だったりして、例外やバグになる。
さらには標準出力が何もないと文字列型である空文字ではなくNULL（AutomationNull）になるし。
外部プログラムの標準出力を受け手が改行ごとに分割して解釈するのはgrep等でよくあるからヘンテコ仕様とは思わないけど、
沢山あるpowershellの落とし穴の1つだと思ってる。
448: 05/19(月)10:22 ID:Z1VKFLAg(1) AAS
$a = @(powercfg.exe -lastwake)
こんなふうにして必ず配列で返るようにするといいです
449: 05/19(月)21:43 ID:qL6NUCv5(1) AAS
キモい記法だな
450: 05/19(月)23:54 ID:2rbfAZ+2(1) AAS
このキモい記法ってコレクション返す関数書くと使わざるを得ないんだよな…
関数とかスクリプト最後のreturnにコレクションを渡すと勝手にバラす謎仕様
最初知らなくてDataTableのつもりがDataRowの配列で返ってきたときはびっくりした
451: 05/20(火)01:53 ID:yO05o0Kw(1) AAS
[string[]]$aで受け取る
452(1): 05/20(火)12:57 ID:NKLxZTlt(1/3) AAS
時刻データ(ISO 8601)が入った JSON を invoke-RestMethod で受け取る
あるいは ConvertFrom-JSON すると時刻が powershell 形式になる
データの内容を見て勝手に変換してるんか…
453(1): 05/20(火)14:18 ID:Xl2+DDPz(1) AAS
>>452
勝手にDateTime型でだしてくるってこと？
454: 05/20(火)15:30 ID:NKLxZTlt(2/3) AAS
>>453
こうなる
(ConvertFrom-Json('{"data":"2025-05-19T16:35:42.000Z"}')).data
2025年5月19日 16:35:42
455: 05/20(火)15:52 ID:NKLxZTlt(3/3) AAS
括弧いらなかった（どうでもいい）
(ConvertFrom-Json '{"data":"2025-05-19T16:35:42.000Z"}').data
456: 05/21(水)09:54 ID:rXr/G70T(1) AAS
ならんが（Win10, Win11, PSv5.1 -nop）
PS C:\Users\User5> (ConvertFrom-Json '{"data":"2025-05-19T16:35:42.000Z"}').data
2025-05-19T16:35:42.000Z
PS C:\Users\User5> (ConvertFrom-Json '{"data":"2025-05-19T16:35:42.000Z"}').data.GetType().FullName
System.String
457: 05/21(水)09:59 ID:2NJ41Wyd(1) AAS
powershell5とpowershell7で動作が違うね
powershell7だと変換される
458: 05/21(水)17:10 ID:NEzFfeHM(1) AAS
大半が5.1しか使わないから7の方が合わせろよって事
459: 05/21(水)18:50 ID:UAEUk5lE(1) AAS
外部ﾘﾝｸ[5]:learn.microsoft.com
PowerShell 6 以降、 ConvertTo-Json はタイムスタンプとして書式設定された文字列を DateTime 値に変換しようとします。
PowerShell 7.5 では、DateKind パラメーターが追加されました。これにより、タイムスタンプ文字列の変換方法を制御できます。 このパラメーターは、次の値を受け入れます。
460: 06/24(火)00:10 ID:9HpiqCeZ(1) AAS
powershell7っていつになったらOS標準搭載されるんだろう
スクリプト配れないから困るんだよね
461: 06/24(火)11:26 ID:F3nFA9Ml(1) AAS
配ればいいじゃん
7で動作確認してますって書いとけばいいだけ
462: 06/24(火)11:45 ID:jKpO0eO6(1) AAS
その小学生低学年みたいな書き込み必要か？
463: 06/24(火)12:05 ID:KEAdRoBs(1) AAS
いつになってもされないよ
Windowsのサポート期間と合わないから、標準で入れたところで結局塩漬けされて第二のPowerShell5になるだけ
そして最新のバージョンのPowerShellは今以上に誰も使わなくなる
.NET4.8のサポートが終了する頃にはとっくにPowerShellは開発終了してるだろうし、無理に移行させる理由がないんだよ
464: 06/24(火)12:24 ID:uXNyGdUq(1) AAS
OS標準搭載とか安定が必要なのはv5を使え、v7は破壊的変更を加えながら育ててくって棲み分けになってるから標準搭載はナイだろうなあ
465: 06/24(火)18:03 ID:sjc0o4g2(1) AAS
6以降はWindowsファーストでUNIXでも動くシェルとしてわりとユニークな立ち位置なのでそれなりに存在価値はあり、
MSスタックどっぷりな人間がAzureをはじめとしてクラウドでLinuxに触れざるを得ないときのハードルを下げるのに役立っている
Winのオンプレ鯖やPCのシェルとしては5までで終わり
466(1): 06/24(火)19:36 ID:ZrkIV361(1) AAS
.NET Framework 4系（4.8.x）がWindowsに同梱され続ける限り、PowerShell 7.xが標準になることはなさそう
Unicodeの年次アプデがもう何年も反映されてなかったり、色々とキツいけど仕方ない
467(1): 06/25(水)00:38 ID:6PeRjodX(1) AAS
powershellで攻めた使い方するくらいならpythonで書くよなぁ
インストール不要で動くという最大のメリットがない7系はpowershell好きにしか響かないと思う
468: 06/25(水)13:28 ID:zWuAHPd0(1) AAS
>>467
逆にpowershell7をインストールしないメリットて何だ
469: 06/25(水)15:20 ID:TZWJXUbx(1) AAS
Pythonをインストールしないメリットと似たようなもん
470: 06/26(木)17:27 ID:lOjfAOzg(1) AAS
powershell 7 が読めない速さで（読めないのでキャプチャした）
”Creating implict remoting module ... [Getting command information from remote session ... 74 commands received 0s]”
とか黄色文字で一瞬表示するの止められないんだろうか
チラチラして鬱陶しい
implict remotingて何だと調べると互換性の無いモジュールを裏でpowershell 5 を起動して処理してるんだとか
Set-Location 程度でも発動する
471(1): 06/28(土)01:00 ID:UBYVDQZY(1) AAS
昔数百万行の各個別コマンドをpowershellでスレッドプール実装して並列処理で捌いたことあったけどvscodeの拡張機能でのデバッグが無かったら諦めてたと思う
拡張機能のおかげで大分開発しやすくなった
472: 06/28(土)16:43 ID:uH6ba5rf(1) AAS
>>471
なぜマルチスレッドの実装にこだわってマルチプロセスにしなかったのか？
スレッドのコントロールは面倒くさい。
互いのスレッドが干渉し合わないなら、別のプロセスとして実装すべき。
473(1): 06/30(月)14:31 ID:+52Dh5n7(1) AAS
「Windows PowerShell 2.0」は非推奨、将来的に削除 〜Microsoftが改めて注意喚起
「Windows PowerShell 5.x」や「PowerShell 7.5」への移行を
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
474(1): 07/08(火)11:07 ID:ub1Gvu25(1/3) AAS
>>397
batの方が重大なミスしそうなんですがそれは
475: 07/08(火)11:08 ID:ub1Gvu25(2/3) AAS
>>398
っぱpwsh on linuxよ
476: 07/08(火)11:16 ID:jxaCuQsN(1) AAS
>>474
よく読め
477: 07/08(火)11:16 ID:ub1Gvu25(3/3) AAS
>>466
何時までも4,5系に留まるってことは無いと思うけどね
実際2からアップグレードされてきた訳だし
.NET Frameworkとの差異は比較的大きいにせよ
>>473の件もあるしそのうちプリインされるだろCore版が
なお6か7かはたまたまだ見ぬ8かは知らんけど
478: 07/09(水)05:32 ID:aeqwBJS6(1/2) AAS
powershellの日本語ドキュメント、chatGPTに翻訳させたらもっとマトモにならんかなあ…
479: 07/09(水)05:34 ID:aeqwBJS6(2/2) AAS
6もしぱらくバグまみれだったし7もバグどんどん見つかっていったし、最新がプリイン入る事は無いと思うな
多分最新の1つ前の最終マイナーバージョン、すなわちもし今なら6の最終バージョンじゃね
480: 07/09(水)06:17 ID:b3V2Axv4(1) AAS
.NET Frameworkと違って.NET5以降がOSに同梱はないでしょ
MS的に推奨かは知らんが関連するライブラリを標準モジュール含めて全部同梱配布が.NET系アプリのスタンダードになってるし今は
だったらロードさせることのないdllをOS標準で入れる意味も無いし未来永劫Powershell6以降は来ないって半分諦めてるけどね
481: 07/09(水)17:36 ID:ohpjpVt+(1) AAS
本日はご多忙の中、協力関係者様にお集まりいただきありがとうございます。
powershellは無事5.1で完結いたしました。
powershell第一部・完
6以降はまた別のお話とさせていただきます。
こんな感じ
482(2): 07/10(木)00:21 ID:z96em9yx(1) AAS
ps1の1は当時はバージョン名の想定じゃなかったっけ
483: 07/10(木)07:27 ID:qajreXxd(1) AAS
>>482
バージョンを表しているのは間違いない
ただ言語のメジャーバージョンとファイルフォーマットの互換性を表すバージョンは必ずしも一致しないって扱いなので、もし次に拡張子が変わるときが来るなら.ps2になる
外部ﾘﾝｸ:devblogs.microsoft.com
Excelを例に取ると97、2007でそれぞれ内部形式が変わっていて、2007では拡張子も変わっているので、いうなれば.xlsxは.xl3に相当するイメージ（5.0以前は無視した場合）
.ps1は最初はバージョンごとに毎回数字を変えるつもりだったけどやめたって説が巷で主流だけど、コレは公式のソースが見つからなかった
484(1): 07/10(木)11:15 ID:DIIl0KYX(1/2) AAS
microsoftは妙に互換性にこだわるから
拡張子.ps1はpowershellがどんなバージョンになっても変わらないよ
今は拡張子に「バージョンの番号が含まれてます」っていう意味すら意味をなくしていて
ただ単に「.ps1はpowershellスクリプトの拡張子です」ってだけの意味でしかないから
今さら拡張子を新しくするメリットが無い
485: 07/10(木)11:20 ID:DIIl0KYX(2/2) AAS
>>484
と思ったけどバージョン5とそれ以降では互換性に問題のある事が多かったなw
そういう誤実行を防止する目的で拡張子を変えるメリットあるかなぁ
486(1): 07/10(木)11:55 ID:nn3AKhN3(1) AAS
もうexeにすればいいんじゃねえかな
powershellで作ったかどうかすら判らんし
487: 07/11(金)21:41 ID:UFItDSPS(1) AAS
外部ﾘﾝｸ:devblogs.microsoft.com
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.
488: 07/12(土)15:57 ID:KKY9VgUr(1) AAS
記事の日付は2007年やぞ
489: 07/14(月)21:23 ID:54I3beLE(1) AAS
PowerShell6で拡張子を変えなかった時点で
この先も.ps1のままなのはほぼ確定だよね
490: 07/15(火)01:51 ID:kwekYfOc(1) AAS
俺たちのJeffrey Snoverはもういない、いないんだ…
491(2): 07/15(火)14:43 ID:iicdRBcv(1) AAS
コマンドプロンプト使ってる人はたくさんいるけど
powershell使ってる人ここ10年で一度も見たこと無い
492: 07/15(火)17:26 ID:J6nh+lbb(1) AAS
>>491
コンソール（の外観）のハナシ？
493: 07/15(火)17:58 ID:eVgbUR/v(1) AAS
俺も、以下の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のみで使用可。
494: 07/15(火)17:58 ID:onP4ElKb(1) AAS
Terminalに移行したら分からなくなっちゃったか
495(1): 07/15(火)18:07 ID:yseOir/R(1) AAS
気軽にスクリプト実行できないから使い道がない
496: 07/15(火)20:54 ID:1cN94XmW(1) AAS
本気で言ってるのか
497: 07/15(火)21:58 ID:ZcYliqlC(1) AAS
弊社はIT企業じゃないし、勝手にPythonを入れたりするとたぶん怒られるので
Windowsに最初から入ってるPowerShellを便利に使ってました
たまに、起動用のbatファイルとPowerShellスクリプトをセットにして同僚に渡すこともありました
498: 07/16(水)08:58 ID:83bEnGjZ(1) AAS
いい加減ペイント３DみたいにPowerShellのアプローチは失敗でしたと認めちゃばいいのに(´・ω・`)
499: 07/16(水)12:43 ID:09DhhKQk(1) AAS
もうログインスクリプトにも使われてるから
Windowsの終焉まで逃げ出せないよ
500: 07/16(水)22:06 ID:5d/ixC+9(1) AAS
PowerShellのどのアプローチが失敗なのか具体的に
501(1): 07/16(水)23:17 ID:7/+dohrQ(1) AAS
起動用のbatが必要になっちゃうってのがな
PowerShell単独では使いにくい
502: 07/16(水)23:57 ID:YcDGevHy(1) AAS
ん？どういうこと？
503: 07/17(木)00:10 ID:sGHKyXGW(1) AAS
ダブルクリック実行できるようにするために手間がかかる
504: 07/17(木)00:22 ID:Nf2HlQRn(1) AAS
正直言ってexecutionpolicyの初期値は大失敗だろうなぁ
結局.batか.cmd経由でダブルクリック起動できるんだからマジで無意味
ネットから落としたファイルはzoneidがあるから設定に関係なく警告でるんだし
あとcmdもPowershellもWindowsのオマケであることに価値があるのにPowershell5.1までしか同梱されてないし
505: 07/17(木)07:33 ID:1VTmgFuN(1) AAS
もう直接powershell.exeに関連付けしてる
506(1): 07/17(木)08:05 ID:9jYPg0KZ(1/5) AAS
>>482
それはバージョン1として普及させただけ。
いまとなってはバージョンを表してはいない。
507(1): 07/17(木)08:06 ID:9jYPg0KZ(2/5) AAS
>>486
それはWindowsしか知らない人間の発想
508(1): 07/17(木)08:08 ID:9jYPg0KZ(3/5) AAS
>>491
Windowsはターミナルというアプリで統合された。
PowerShellはコマンドプロンプトも含めているので、あなたが気づいていないだけ。
509(1): 07/17(木)08:09 ID:9jYPg0KZ(4/5) AAS
>>495
実行形式にする必要がない。UNIX、Linuxは実行形式ファイルを嫌う。
ブラックボックス化はやめろ！
510(1): 07/17(木)08:11 ID:9jYPg0KZ(5/5) AAS
>>501
バッチファイルにする必要もないよ？
バッチファイルなどでラッピングするのはWindowsの使い方のひとつでしかない。
511: 07/17(木)09:38 ID:+XuQIino(1) AAS
>>506-510
全部元発言者を意図を読み取れてない馬鹿のレス
UNIX使いの印象を悪くするだけなのでやめてくれ
512: 07/17(木)12:08 ID:uGnrWKuf(1) AAS
powershellは小数点以下のバージョンアップでも毎回互換性を壊す
破壊的変更を入れてくるから普及させる気無いんじゃね
513: 07/17(木)12:30 ID:l8YWhCPU(1) AAS
実際、6以降は普及させる気無いと思うよ
Azure関連を中心にMS社内で使うために開発続けてるだけでしょ
514: 07/17(木)21:54 ID:yTEYa8cJ(1) AAS
PowerShellが失敗作じゃないと困る人がいるのは分かった
515(1): 07/17(木)22:59 ID:o0/3IwZx(1) AAS
PowerShell自体の出来はともかく、6以降は周辺環境がね
PowerShellは.NETがWindowsの中核として位置付けられていた頃に設計されており、
システムワイドにインストールされた.NETに安定的に依存できることが大前提なのよ
知っての通りその前提は完全に覆されてしまい、存在意義を失おうとしている
516: 07/18(金)01:15 ID:T97Bau37(1) AAS
知っての通りどころか.net frameworkは今もWindowsと一蓮托生だけど
.netと.net frameworkを分けて書かないと意味不明な文章が出来上がる
517(2): 07/18(金)22:16 ID:avd6O0J8(1) AAS
Windows以外で.Netで作られたアプリやサービスなんてあんの？
518(1): 07/18(金)22:17 ID:r2egjf+1(1) AAS
pythonで良くない？駄目？
519: 07/19(土)02:03 ID:QndlLNYI(1) AAS
pwsh.exe
520: 07/19(土)08:55 ID:jBcCcJ6x(1) AAS
>>518
Pythonがそこまで言い言語だとは思わないので
521: 07/19(土)10:16 ID:F2LZk1nd(1) AAS
>>517
ゲームエンジンのUnity
522: 07/19(土)19:43 ID:PVxrNHN1(1) AAS
>>517
GitHub Actions
523(2): 07/20(日)10:33 ID:8UONs9WI(1) AAS
>>515は、元はシステム全体でひとつの.NETフレームワークを使ってPowerShellをCOMに対するWSHポジにするつもりだった、という意味だろうけど
.NETフレームワーク自体最初から複数バージョンを共存させる設計になってるので、果たしてそのような構想はあったのだろうか
524: 07/20(日)11:36 ID:nDfpIeCg(1) AAS
>>523
5以前のPowerShellはサイドバイサイドに対応していないから、使用される.NET Frameworkは結局一つだけ
525: 07/24(木)02:44 ID:uw32EQ1Q(1) AAS
>>523
> .NETフレームワーク自体最初から複数バージョンを共存させる設計になってるので、果たしてそのような構想はあったのだろうか
.net frameworkはそんな設計じゃないぞ…
526: 07/24(木)18:49 ID:bvlLnJ99(1) AAS
コマンドレットを作ったが中途半端で.NET Frameworkを呼び出せばいいということにしたが、これではPowerShellを作った意味がないとしてPowerShellを拡張していまの混乱状態に至る。
527: 07/24(木)20:21 ID:3SMUfFNx(1) AAS
PowerShell独自の構文や機能はいらん .Net実行できる部分だけでいい
C#Scriptがほしい
528(1): 07/24(木)21:28 ID:Ii6lkj2E(1) AAS
C#コードを単一ファイルでスクリプトのように書ける言語機能が「.NET 10」でテスト中
従来のプロジェクトベースへの変換も簡単
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
529: 07/24(木)22:28 ID:qxgm8L3v(1) AAS
powershellのAdd-Typeを使えばC#を実行出来るらしいが
530: 07/26(土)11:52 ID:VPjMt5X4(1) AAS
Add-TypeのC#は、Windows API使いたい時、局所的に処理速度を上げたい時によく使う。
531: 07/26(土)19:50 ID:kldGNMpl(1/2) AAS
ぜんぜん分からないんですけどAdd-TypeでC#を書くのって
インテリセンスが効かなそうで、ちょっとしんどそうなんですけど
そうでもないんですか
532: 07/26(土)20:51 ID:eh3q3MEs(1) AAS
PowerShellで使う程度のものなら余裕でバイブコーディングでいけるからどうでもいい
533: 07/26(土)22:09 ID:kldGNMpl(2/2) AAS
なるほど
534(1): 07/27(日)01:39 ID:sXx2dSLi(1) AAS
もっとc#に近い記法にしてほしかったのになんでそうならなかったんだろう
配列の宣言とかセミコロンがないとか
535: 07/27(日)05:42 ID:L6p6i+Me(1) AAS
クラスはほぼC#だけど
536: 07/27(日)08:16 ID:/sb9ajQY(1) AAS
PowerShellは名前の通りシェルだからな
単なるスクリプト言語が欲しいだけならWSH.NET的なものを作ってる
537: 07/27(日)09:15 ID:zaK1ilRt(1) AAS
今のMSだったらRustあたりで作ったWindows CLIで一通りの管理タスクを一貫したコマンド体系でやれるようにした上で、
スクリプトはbashでもPythonでも何でも好きなの使えみたいにしてるだろうね
今となってはPowerShellはバルマー時代の古き悪きMSを象徴する遺産の一つ
538(3): 07/28(月)09:16 ID:BMbzFeOA(1) AAS
最初はbashの採用を検討してたけどWindowsには向かないって分かったからわざわざPowerShellを作ったんだが
外部ﾘﾝｸ:x.com
539: 07/28(月)10:39 ID:dloezDzP(1/2) AAS
>>538
その理由はファイル指向のUNIXと違ってWindowsはAPI指向だからとJeffreyは述べてるんだけど、
一方でUNIX的なシェルで扱うのに適したCLIコマンドを整備するという方向もありえて、
実際MSがPowerShellにベットする以前はWMICのようにラッパーとしてCLIコマンドを整備していく方針だったんだよ
ただ、その方向で進む限りWindows上でのコマンドラインシェルは特殊なラッパーに依存することになり、決してWindowsスタックにおける主流になり得ない
そこで当時Windowsの新たな中核技術として喧伝されていた.NETプラットフォームに乗ることで、
MS社内にサービスしつつ一気にWindowsでのコマンドラインシェルを主流に押し上げようとしたわけだね
で現状はというと、肝心の.NETが主流から外されちゃって、PowerShellは一般のアプリの一つになっちゃいました(いまここ
540: 07/28(月)11:02 ID:dloezDzP(2/2) AAS
あと、現状について周辺の情勢も踏まえると、CLIを使ってAPI指向のプラットフォームを管理するスタイルはPowerShell 初期開発の当時と比較して遥かに市民権を得ているといえる
それはひとえにクラウドによるもので、現在ではクラウドプラットフォームのAPIをCLIを使って操作することは普通に行われており、しかもその多くはJeffreyの懸念に反して旧来のUNIXシェルを使用している
この現状を踏まえて今Windowsのコマンドライン管理を再考するとすれば、PowerShellのようなものが生まれる可能性は低いといえる
541(1): 07/28(月)17:29 ID:CQsGHQXP(1) AAS
Windowsは(少なくともOLE〜.NET全盛期の頃のWindowsは)APIもオブジェクト指向する方向性だったので
それを操作するスクリプト言語もCOMオブジェクトや.NETオブジェクトを長期保持できなければいけない
単発で終了するCLIコマンドを揃えてもだめだろう
542: 07/28(月)19:14 ID:7Fge/X80(1) AAS
おっさんエンジニアが全然使わないから無理だわ
543: 07/28(月)19:32 ID:K95kqw+R(1/5) AAS
>>528
それだとVBScriptの二の舞
544: 07/28(月)19:33 ID:K95kqw+R(2/5) AAS
>>534
そこがマイクロソフトの変なところ
いろんなプログラミング言語を研究して最良のものを作ったというのが当初の売り文句だった
545: 07/28(月)19:34 ID:K95kqw+R(3/5) AAS
>>538
それはプライドが許さなかっただけ
546: 07/28(月)19:35 ID:K95kqw+R(4/5) AAS
>>538
グーグルおじさんじゃねえか
547: 07/28(月)19:37 ID:K95kqw+R(5/5) AAS
>>541
WindowsはWindows SDK開発がC言語でもC++でもいいというところから始まったせいで、形だけオブジェクト指向のC++が基本になってしまった。
548: 07/28(月)20:23 ID:0zFGFjxD(1) AAS
後発だからいろんな言語を参考にできるという強みがある一方で
Windowsのシェルスクリプトという世界最大級のしがらみのもと
あらゆるステークホルダーが全方位から好き勝手なことを言い
無数の歴史的経緯を踏まえつつデザインしないといけない無理ゲーなプロジェクト
変なクセが多い言語だけど苦労が偲ばれるからあまり文句を言う気にはなれない
549: 07/28(月)20:35 ID:n+5V5/p3(1) AAS
CとB-Shellが混じったような半端な記法
550(1): 07/28(月)21:11 ID:s3rviGhL(1) AAS
今なら普通にTypeScriptになるだろうね
551: 07/28(月)21:57 ID:pEErs1kG(1) AAS
bat埋込み技法とAdd-Typeでcsスクリプト化したった
スクリプトのくせに起動が遅いのが不満
552(1): 07/29(火)08:49 ID:zbO0uIbs(1) AAS
パイプにバイナリが流せるようになったPowerShell 7.4 からは使える子になった
553: 07/29(火)12:01 ID:0YhddUmf(1) AAS
VBSもなんやかんや生き続けると思ったけどOSとしてサポート終了となれば話しは別やな
554: 07/29(火)14:11 ID:/sYzcWbW(1) AAS
>>552
パイプにバイナリ通せるつって1バイトずつbyteで送られてきても困るんだが
実際のとこどうなっとんの
555: 07/29(火)17:07 ID:HrDR44lc(1) AAS
コマンド間にControl-Streamかまして調整する
556: 07/29(火)21:53 ID:J2wyXy1Z(1) AAS
>>550
.NET対応のスクリプト言語なら静的型付けなJScript.NETが前からあるんだから
TypeScriptなんて中途半端な言語はいらない
Introducing JScript .NET
外部ﾘﾝｸ:learn.microsoft.com
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s