PowerShell -Part 7

**デフォルトの名無しさん** · 2024/12/18(水) 15:12:46.26

>>361
Windowsのスタートメニューを見たことがないのか？

PowerShell ISEは無視、Visual Studioも無視するなら、あなたの希望通りにVSCodeになるな。

**デフォルトの名無しさん** · 2024/12/18(水) 22:53:36.03

いや普通にVSCode一択だよ
ISEは開発停止がアナウンスされてMicrosoft自身がVSCodeを推奨してる

**デフォルトの名無しさん** · 2024/12/18(水) 23:49:49.43

powershellの開発環境としてvisual studioが挙がることってあるか…？

**デフォルトの名無しさん** · 2024/12/19(木) 00:10:06.38

VScodeなら分かる

**デフォルトの名無しさん** · 2024/12/21(土) 16:45:21.87

.ps1のスクリプトを右クリックから実行しようとすると
最初に[実行ポリシーを変更しますか？…]というのが出て、キーボード操作が必要になるんだけど
これは出ないようにできないのかな？

**デフォルトの名無しさん** · 2024/12/21(土) 17:27:08.04

うろ覚えだけど
右クリからやるやつはポリシーがhogeだったらbypassにするみたいなif文が入ってた気がする
レジストリで変えれたはずだけど出先だから細かくは分かんないや
適当にググったら出てくるんじゃないかな

それかif文にかからないようにポリシーの方を変える

**デフォルトの名無しさん** · 2024/12/21(土) 17:47:50.11

>>367
できました！
ありがとうございます

**デフォルトの名無しさん** · 2024/12/21(土) 19:56:38.76

>>368
間違って実行してしまわないよう、わざわざそういう仕様になっていることを忘れないように

**デフォルトの名無しさん** · 2024/12/21(土) 19:57:11.83

>>368
バッチファイルというものを知った方がいい

**デフォルトの名無しさん** · 2024/12/21(土) 20:34:08.41

的外れなレス付いてんなw

**デフォルトの名無しさん** · 2024/12/23(月) 10:35:42.88

バッチこい

**デフォルトの名無しさん** · 2024/12/24(火) 22:41:53.48

>>371
そもそもGUIで人間の操作で実行というのが変

何のための自動化なのかわからない

**デフォルトの名無しさん** · 2024/12/24(火) 23:14:00.94

どこからGUIの話が出てきたんだ…？

**デフォルトの名無しさん** · 2024/12/25(水) 17:59:30.20

>>374
「右クリック」と書いてある

**デフォルトの名無しさん** · 2024/12/25(水) 21:34:02.80

ps1で思考停止するような子を見てるとそう
もっと頭を使う訓練を教育機関で受けさせとかないとやばいのではと総務省に問い質したくなるね

**デフォルトの名無しさん** · 2024/12/26(木) 00:31:28.78

総務省…？

**デフォルトの名無しさん** · 2024/12/27(金) 11:14:09.84

>>373
ps1ファイルを右クリでpwshコンソールが起動してスクリプトが実行される
て普通にあることだと思うが

**デフォルトの名無しさん** · 2024/12/27(金) 12:09:30.67

もう既に解決して終わってるし、>>366に書いてることをもう一度書く必要はない

**デフォルトの名無しさん** · 2025/01/02(木) 12:24:43.46

$s = "昔し羅馬にこう云う話しがある。後学のため聞いておけと云うんです"
Write-Host -ForegroundColor Red -BackgroundColor Black "$($s[12]) $($s[24]) $($s[23]) $($s[19])"

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

>>378
それはGUIの操作

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

実行形式のファイルを実行するときにしつこく確認する仕組みに変化した歴史も知らないんだろ。

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

的外れ過ぎる

**デフォルトの名無しさん** · 2025/01/08(水) 09:05:49.08

＞実行形式のファイルを実行するときにしつこく確認する仕組み

何それ

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

gci C:\Windows -include *.log,*.dat
は要素が一つも出なくて
gci C:\Windows\*.* -include *.log,*.dat
gci C:\Windows -recurse -include *.log,*.dat
はOKってどういう理屈なの？
できれば一番上の書きかたしたい…

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

>>385
仕様。
https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1#4-include

理屈は知らん。過去ログになんかあったような、ちょっと違ったような。（-Filterの話だったような）

**デフォルトの名無しさん** · 2025/01/12(日) 14:27:17.12

初期リリースで適当に用意されたコマンドレットの仕様が残ってるだけだから理屈なんて無いだろうよ
gciのオプションは普通の人の感覚と違うからWhere-Objectにパイプで渡してフィルタする方がおかしな事にならないよ

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

末尾のスラッシュの有無でフォルダ自体を指すのかその配下を指すのかを区別するのはUNIXでは割と珍しくないだろう
Windowsだとファイルパスを文字列というより何らかのエンティティを参照するものと考える傾向があるから馴染みにくいわな

**デフォルトの名無しさん** · 2025/01/14(火) 19:43:42.33

この話は末尾がスラッシュかどうかは関係ないよ
Include, Excludeを使うときはワイルドカードを含めないとPathで指定した項目自身しかヒットしなくなるというこのコマンドレット固有ルールの話

**デフォルトの名無しさん** · 2025/01/27(月) 01:42:20.03

V7.47
https://github.com/PowerShell/PowerShell/releases/tag/v7.4.7
V7.5
https://github.com/PowerShell/PowerShell/releases/tag/v7.5.0
が出ました

**デフォルトの名無しさん** · 2025/01/27(月) 01:43:08.84

今回から.exeがある。

**デフォルトの名無しさん** · 2025/01/27(月) 21:48:58.99

.exe版と.msi版の違いが分からん
.msiだと問題が起きる環境でもあるのか

**デフォルトの名無しさん** · 2025/01/27(月) 22:00:26.88

MDMで配れない

**デフォルトの名無しさん** · 2025/02/05(水) 01:17:36.51

powershellの実行権限デフォルトで縛ってるのなんでなの
batは縛ってないのに

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

batが作られた時代はセキュリティという概念がほとんどなかった
いまや甘いと社会的影響も甚大で徹底的に叩かれる時代
何もわからない初心者がメールに添付されたスクリプトを実行できなくて困惑するくらいで丁度いい
batという穴が残っているといってもいまは過渡期
移行する選択肢がありたとえば組織のルールで禁止してメールフィルタで弾けばいい

**デフォルトの名無しさん** · 2025/02/05(水) 11:32:38.10

情弱は我慢して使えってこと

**デフォルトの名無しさん** · 2025/02/07(金) 21:28:42.53

>>394
誰でも間違って重大ミスをする方がいいのか？

**デフォルトの名無しさん** · 2025/02/08(土) 08:16:37.94

https://learn.microsoft.com/ja-jp/powershell/scripting/security/security-features
＞実行ポリシーは、Windows プラットフォームにのみ適用されます。

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about_execution_policies
＞ Windows 以外のコンピューターでは、既定の実行ポリシーは Unrestricted され、変更できません。 Set-ExecutionPolicy コマンドレットは使用可能ですが、PowerShell はサポートされていないというコンソールメッセージが表示されます。 Windows 以外のプラットフォームでは Get-ExecutionPolicy は Unrestricted を返しますが、これらのプラットフォームは Windows セキュリティゾーンを実装していないため、実際の動作は Bypass と一致します。

なんだこの差は

**デフォルトの名無しさん** · 2025/02/08(土) 08:24:47.70

草

**デフォルトの名無しさん** · 2025/02/08(土) 08:47:04.49

マルチプラットフォームで社外の全システムに対応するのもめんどくさそうだしある程度はええやろ
UNIXならパーミッションを適切に設定する文化が馴染んでるしな
100点満点じゃないと人様に叩かれる文化は新しいものが生み出せずに萎縮する

**デフォルトの名無しさん** · 2025/02/08(土) 13:21:14.91

バッチファイルでも実行権限を持たせる事はできるんだから
powershell独自のやつは余計なんだよ

**デフォルトの名無しさん** · 2025/02/08(土) 15:13:57.11

.ps1はエディタに紐付け

**デフォルトの名無しさん** · 2025/02/08(土) 15:51:11.00

メモ帳に紐付けてます

**デフォルトの名無しさん** · 2025/02/13(木) 09:12:08.62

PowerShell 7.5 GA is now available
https://devblogs.microsoft.com/powershell/announcing-powershell-7-5-ga/

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

Selectボタンでファイルを選択した後にOKボタンを押下しても、$filePathにファイル名が代入されていません。何が原因でしょうか？
ttps://pastebin.com/a3EwP1Lw

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

>>405
テキストボックスには選択したファイルのパスが表示されてるのに、ってこと？

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

scope的に$filePath揮発してたりしない？

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

関数内で外のスコープの変数に代入する場合はスコープ指定（script: や global:）が必要だったかも

**デフォルトの名無しさん** · 2025/02/18(火) 19:01:09.96

>>406
はい、そうです。

>>407
多分$filePathが揮発しているのだと思うのですが、何故そうなるのかが正直分かっておりません。

>>408
$global:filePath = $null
$script:filePath = $null
に書き換えても結果は同じでした。orz

**デフォルトの名無しさん** · 2025/02/18(火) 21:38:36.15

>>409
408の内容理解してないだろ

**デフォルトの名無しさん** · 2025/02/18(火) 21:45:12.87

$button_Select.Add_Clickの中の　$filePath = $dialog_fileSelection.FileName　を　$script:filePath　に変える

そもそもイベントハンドラの書き方おかしくない？
Add_Click{}　じゃなくて　Add_Click({})　でしょ

**デフォルトの名無しさん** · 2025/02/18(火) 21:45:47.23

>>409
惜しいw

スコープ指定が必要なのは関数内の代入文側であって、外にある変数定義側ではないよ

**デフォルトの名無しさん** · 2025/02/19(水) 05:46:44.36

>>411
ありがとうございます！
$filePathにファイルパスが代入されるようになりました。

>>412
ありがとうございます。
そうだったんですね。勉強になりました。

**デフォルトの名無しさん** · 2025/03/01(土) 22:23:09.05

ttps://pastebin.com/THGpvEsL

ファイルを何も選択していない状態でOKボタンを押下すると、メッセージダイアログボックス「"Please select a file."」が表示され、そのダイアログボックスのOKボタンを押下すると、処理？が終了してしまいます。
OKボタンを押下した際に、そのメッセージダイアログボックス「"Please select a file."」だけ消すにはどうしたらいいでしょうか？

**デフォルトの名無しさん** · 2025/03/02(日) 03:09:52.22

>>414
当たり前だけど、下記を削除するしかない

$button_OK.DialogResult = "OK"

**デフォルトの名無しさん** · 2025/03/02(日) 07:10:25.55

>>415
ありがとうございます！

**デフォルトの名無しさん** · 2025/03/04(火) 14:43:31.10

Microsoft Update changes for PowerShell 7
https://devblogs.microsoft.com/powershell/microsoft-update-changes-for-powershell-7/
「Microsoft Update」を用いた「PowerShell 7」のアップデート計画が変更
まだ「PowerShell 7.2」を利用している場合、米国時間3月14日より7.4へ更新開始
https://forest.watch.impress.co.jp/docs/news/1667304.html

**デフォルトの名無しさん** · 2025/03/07(金) 19:36:07.86

Input Folder用のボタンを押下して対象のフォルダを選択した後、OKボタンを押下すると選択した対象のInputフォルダのパスが取得されていません。
変数スコープまたは"function setSelectButton"におけるswitchが機能していないのおもうのですが、何が原因でしょうか？
Copilotに聞いてもダメでした。ボタンなどの部品は関数化しないほうがいいのでしょうか？

ttps://pastebin.com/ULTy9dM8

**デフォルトの名無しさん** · 2025/03/07(金) 23:19:13.53

Add_Clickに渡したスクリプトブロックが実行されるのはボタンクリック時。
その時にはもうsetSelectButtonを抜けてるから、setSelectButton実行時に渡した$folderTypeはもう見えない。

最後の手段的なglobalスコープの使用を避けて手っ取り早く解決するなら、
{～～～}.GetNewClosure()でsetSelectButton実行中の変数スコープを記憶（？）したうえで
自前のクラスとかハッシュテーブル等で入出力しちゃう。とか。適当実装だとこんな。

function setSelectButton($def){
$conf = New-Object System.Windows.Forms.Button
$conf.Location = New-Object System.Drawing.Point($def.xAxis,$def.yAxis)
$conf.Size = New-Object System.Drawing.Size($def.xSize, $def.ySize)
$conf.Text = "Select"
$conf.Add_Click({
　　$dialog_FolderSelection = New-Object Windows.Forms.FolderBrowserDialog
　　if($dialog_FolderSelection.ShowDialog() -eq [System.Windows.Forms.DialogResult]::OK){
　　　　$def.textBox.Text = $dialog_FolderSelection.SelectedPath
　　}
}.GetNewClosure())
return $conf
}
（略）
$inputDef = [Ordered] @{xAxis = 370; yAxis = 50; xSize = 70; ySize = 20; textBox = $textBox_inputFolder;}
$outputDef = [Ordered] @{xAxis = 370; yAxis = 70; xSize = 70; ySize = 20; textBox = $textBox_outputFolder;}
# create Select button
$button_Select_inputFolder = setSelectButton $inputDef
$button_Select_outputFolder = setSelectButton $outputDef
（略）
if([String]::IsNullOrEmpty($inputDef.textBox.Text)){ # show a message dialog if no file is selected

※これで入力欄にフォルダパスをコピペする人（＝私）も安心

**デフォルトの名無しさん** · 2025/03/08(土) 23:41:12.69

画面用のコードがひどすぎるのがPowerShell

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

>>419
ありがとうございます！
setSelectButton実行時に渡した$folderTypeはもう見えないんですね。

**デフォルトの名無しさん** · 2025/03/11(火) 21:13:50.84

Windows 11 バージョン 24H2 で netsh.exe の出力を PowerShell の変数に代入すると、非 ASCII 文字が文字化けする事象について
https://jpwinsup.github.io/blog/2025/03/11/Networking/TCPIP/NetshEncodingChange24h2/

**デフォルトの名無しさん** · 2025/04/26(土) 01:37:45.27

ttps://pastebin.com/0HrXEMvc
のHTMLソースから特定のDIVクラス「KW」とそのクラスないを削除する方法はありましでしょうか？
以下ではきえませんでした
# HTML読み込み
$targetDir = "D:\Download\test\sample.html"
$html = Get-Content "D:\Download\test\sample.html" -Raw

# KWクラスdivを正規表現で削除
$pattern = '<div\s+class="KW">[\s\S]*?<\/div>'
$modifiedContent = $htmlContent -replace $pattern, ''

# 結果出力
$processedHtml | Out-File "D:\Download\test\pit.html" -Encoding UTF8

**デフォルトの名無しさん** · 2025/04/26(土) 21:00:04.39

>>423
なんで変数の対応がめちゃくちゃなの？
正規表現で力技でやるとこんなところだが
xmlとして読み込めばnode削除でいけそうな気がする
Add-Type -AssemblyName Microsoft.VisualBasic
$html = Get-Content "D:\Download\test\sample.html" -Raw

# KWクラスdivを正規表現で削除
$pattern = [regex]"^((?:(?'open'<div[^>]*?>[\r\n]*))|(?'close-open'</div>)|(?:(?!</?div[^>]*>)[\s\S])+?)*(?(open)(?!))"
$processedHtml=$pattern.replace($html,{
$r=$args.value
$e=0
$args.groups['3'].captures|
sort index|
?{$_.index+$_.length -gt $e -and $_.value -cmatch '<div.*class="KW"'}|
%{$e=$_.index+$_.length; $r=[Microsoft.VisualBasic.Strings]::replace($r,$_.value,"",1,1)}
$r
})
$processedHtml | Out-File "D:\Download\test\pit.html" -Encoding UTF8

**デフォルトの名無しさん** · 2025/04/26(土) 23:51:52.55

ttps://pastebin.com/0M9pbEJt
みたいなHTMLから特定のDIVクラス（kw）で定義されている要素を全部削除したいのですが、何かいい方法ありますでしょうか？

**デフォルトの名無しさん** · 2025/04/27(日) 15:25:40.97

>>425　（>>423と同一人物だよね）
>>424に礼を言ったうえで、どの点が自身の質問意図に合ってなかったか説明して、
それからもっと具体的に追加質問した方がいいと思うよ。
ところで「xmlとして読み込めばnode削除でいけそう」は試してから言ってるの？何が合わなかったの？

**デフォルトの名無しさん** · 2025/04/27(日) 16:50:54.99

滝川クリトリスです

**デフォルトの名無しさん** · 2025/04/27(日) 20:14:14.77

楽しようとして初回マッチ部分のみのreplace使ったけど
やっぱり別のが消えちゃうという一抹の不安があるのでreplaceを使うのはやめた
最終行に改行がないままにしたいのかな？
$html = Get-Content "D:\Download\test\sample.html" -Encoding UTF8 -Raw

# KWクラスdivを正規表現で削除
$pattern = [regex]"^((?:(?'open'<div[^>]*?>[\r\n]*))|(?'close-open'</div>)|(?:(?!</?div[^>]*>)[\s\S])+?)*(?(open)(?!))"
$processedHtml=$pattern.replace($html,{
$r=$args.value
$text=''
$e=0
$args.groups['3'].captures|
sort index|
?{$_.index+$_.length -gt $e -and $_.value -cmatch '<div[^>]*?class="KW"'}|
%{
$text = $text + $html.substring($e, $_.index-$e-1);
$e = $_.index + $_.length - 1
}
if($r.length -gt $e) {$text = $text + $r.substring($e, $r.length-$e)}
$text
})

[Text.Encoding]::GetEncoding("UTF-8").GetBytes($processedHtml) | Set-Content -Path "D:\Download\test\pit.html" -Encoding Byte

**デフォルトの名無しさん** · 2025/04/27(日) 20:24:25.83

>>426
試してませんでした
HTMLやxmlを扱うことはほぼ無いのであんまり知識が無い
で、>>423の場合では[xml]で読み込めてnode削除でうまくいくんだが
入れ子になってる場合
<div class="KW">
<span>
<div class="KW">
</div>
</span>
</div>
とかにはどうやったら簡単に対応できるのかと思ってるところ

**デフォルトの名無しさん** · 2025/04/27(日) 22:05:35.62

中身全部消すのであれば内側のKWは無視していいのでは

**デフォルトの名無しさん** · 2025/04/27(日) 22:11:37.95

簡単には
$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"の存在とか、インデント等を完璧に維持したい、とかは考慮外。

**デフォルトの名無しさん** · 2025/04/27(日) 22:22:47.91

>>431
なるほど
こんな感じにしてたんだよ
$list=@()
$doc.GetElementsByTagName('div')|?{$_.class -eq "KW"}|%{$list+=$_}
$list|%{[void]$_.ParentNode.RemoveChild($_)}

**デフォルトの名無しさん** · 2025/04/27(日) 22:48:33.11

悩んでたのは
既に削除しちゃてて存在しない場合にエラー無視はやりたくないなあってところ

**デフォルトの名無しさん** · 2025/05/02(金) 21:45:21.05

powershellって日本語に厳しい？
日本語名のフォルダに入れた時だけエラー吐く
英語名フォルダは動く
UTF-8BOMで保存してるのに文字化けエラーが治らない

**デフォルトの名無しさん** · 2025/05/02(金) 22:24:03.09

いわゆる「マルチバイト文字」のことを「日本語」と呼ぶのはジジイ

**デフォルトの名無しさん** · 2025/05/03(土) 07:39:35.24

UTF-8にBOMは不要

**デフォルトの名無しさん** · 2025/05/03(土) 17:59:32.71

文字コードが混在するシステムではBOMがあると便利です

**デフォルトの名無しさん** · 2025/05/03(土) 18:08:41.88

それが更に文字コードのバリエーションを増やし失敗を生むのだから本末転倒です

**デフォルトの名無しさん** · 2025/05/03(土) 18:08:56.03

PowerShellスクリプトは「UTF-8 with BOM」が前提

>>434
実行時（コンソール）のコードページを確認してみては？

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

shift-jisにすればいいんじゃないの？

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

適切なエンコードの選択
https://learn.microsoft.com/ja-jp/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding#choosing-the-right-encoding

**デフォルトの名無しさん** · 2025/05/04(日) 11:02:36.68

文字化け対策は
　[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
こういうのをpowershellのプロファイルに書き込んで
powershell起動時に文字エンコードが適切な値になるようにしておく
そしてコンソールのタイトルバーを右クリして設定で適切なフォントが使用されてるか確認

**デフォルトの名無しさん** · 2025/05/09(金) 16:18:47.82

>>434 とは別人だが、レジストリ弄ったら文字化けしなくなったわ
初心者泣かせのクソ仕様だな

**デフォルトの名無しさん** · 2025/05/10(土) 10:47:55.61

>>443
powershellをアップデートしたらリセットされそうな予感

**デフォルトの名無しさん** · 2025/05/10(土) 15:03:05.65

>>444
文字化けするようになったのはプロパティでコンソール画面の調整を行ってから
デフォルトの状態では文字化けしていなかったのでたぶん大丈夫…と思う

**デフォルトの名無しさん** · 2025/05/18(日) 16:44:31.56

$a = powercfg.exe -lastwake
$aは文字列かと思ったら文字列の配列だった…

コマンドの出力に改行が無ければ文字列、含む場合は配列とかいうヘンテコ仕様は何なんだ

**デフォルトの名無しさん** · 2025/05/18(日) 19:51:20.44

この振る舞いを知らないと、$a.Lengthが時により文字列長だったり配列長だったりして、例外やバグになる。
さらには標準出力が何もないと文字列型である空文字ではなくNULL（AutomationNull）になるし。
外部プログラムの標準出力を受け手が改行ごとに分割して解釈するのはgrep等でよくあるからヘンテコ仕様とは思わないけど、
沢山あるpowershellの落とし穴の1つだと思ってる。

**デフォルトの名無しさん** · 2025/05/19(月) 10:22:41.03

$a = @(powercfg.exe -lastwake)
こんなふうにして必ず配列で返るようにするといいです

**デフォルトの名無しさん** · 2025/05/19(月) 21:43:03.14

キモい記法だな

**デフォルトの名無しさん** · 2025/05/19(月) 23:54:30.60

このキモい記法ってコレクション返す関数書くと使わざるを得ないんだよな…
関数とかスクリプト最後のreturnにコレクションを渡すと勝手にバラす謎仕様

最初知らなくてDataTableのつもりがDataRowの配列で返ってきたときはびっくりした

**デフォルトの名無しさん** · 2025/05/20(火) 01:53:43.90

[string[]]$aで受け取る

**デフォルトの名無しさん** · 2025/05/20(火) 12:57:58.71

時刻データ(ISO 8601)が入った JSON を invoke-RestMethod で受け取る
あるいは ConvertFrom-JSON すると時刻が powershell 形式になる
データの内容を見て勝手に変換してるんか…

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

>>452
勝手にDateTime型でだしてくるってこと？

**デフォルトの名無しさん** · 2025/05/20(火) 15:30:07.39

>>453
こうなる

(ConvertFrom-Json('{"data":"2025-05-19T16:35:42.000Z"}')).data

2025年5月19日 16:35:42

**デフォルトの名無しさん** · 2025/05/20(火) 15:52:27.90

括弧いらなかった（どうでもいい）
(ConvertFrom-Json '{"data":"2025-05-19T16:35:42.000Z"}').data

**デフォルトの名無しさん** · 2025/05/21(水) 09:54:31.02

ならんが（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

**デフォルトの名無しさん** · 2025/05/21(水) 09:59:36.90

powershell5とpowershell7で動作が違うね
powershell7だと変換される

**デフォルトの名無しさん** · 2025/05/21(水) 17:10:41.92

大半が5.1しか使わないから7の方が合わせろよって事

**デフォルトの名無しさん** · 2025/05/21(水) 18:50:19.37

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.utility/convertfrom-json?view=powershell-7.5#notes

PowerShell 6 以降、 ConvertTo-Json はタイムスタンプとして書式設定された文字列を DateTime 値に変換しようとします。

PowerShell 7.5 では、DateKind パラメーターが追加されました。これにより、タイムスタンプ文字列の変換方法を制御できます。このパラメーターは、次の値を受け入れます。

**デフォルトの名無しさん** · 2025/06/24(火) 00:10:17.72

powershell7っていつになったらOS標準搭載されるんだろう
スクリプト配れないから困るんだよね

**デフォルトの名無しさん** · 2025/06/24(火) 11:26:30.59

配ればいいじゃん
7で動作確認してますって書いとけばいいだけ

**デフォルトの名無しさん** · 2025/06/24(火) 11:45:12.25

その小学生低学年みたいな書き込み必要か？

**デフォルトの名無しさん** · 2025/06/24(火) 12:05:00.87

いつになってもされないよ
Windowsのサポート期間と合わないから、標準で入れたところで結局塩漬けされて第二のPowerShell5になるだけ
そして最新のバージョンのPowerShellは今以上に誰も使わなくなる
.NET4.8のサポートが終了する頃にはとっくにPowerShellは開発終了してるだろうし、無理に移行させる理由がないんだよ

**デフォルトの名無しさん** · 2025/06/24(火) 12:24:16.18

OS標準搭載とか安定が必要なのはv5を使え、v7は破壊的変更を加えながら育ててくって棲み分けになってるから標準搭載はナイだろうなあ

**デフォルトの名無しさん** · 2025/06/24(火) 18:03:39.76

6以降はWindowsファーストでUNIXでも動くシェルとしてわりとユニークな立ち位置なのでそれなりに存在価値はあり、
MSスタックどっぷりな人間がAzureをはじめとしてクラウドでLinuxに触れざるを得ないときのハードルを下げるのに役立っている
Winのオンプレ鯖やPCのシェルとしては5までで終わり

**デフォルトの名無しさん** · 2025/06/24(火) 19:36:57.27

.NET Framework 4系（4.8.x）がWindowsに同梱され続ける限り、PowerShell 7.xが標準になることはなさそう
Unicodeの年次アプデがもう何年も反映されてなかったり、色々とキツいけど仕方ない

**デフォルトの名無しさん** · 2025/06/25(水) 00:38:29.01

powershellで攻めた使い方するくらいならpythonで書くよなぁ
インストール不要で動くという最大のメリットがない7系はpowershell好きにしか響かないと思う

**デフォルトの名無しさん** · 2025/06/25(水) 13:28:46.57

>>467
逆にpowershell7をインストールしないメリットて何だ

**デフォルトの名無しさん** · 2025/06/25(水) 15:20:42.55

Pythonをインストールしないメリットと似たようなもん

**デフォルトの名無しさん** · 2025/06/26(木) 17:27:15.49

powershell 7 が読めない速さで（読めないのでキャプチャした）
”Creating implict remoting module ... [Getting command information from remote session ... 74 commands received 0s]”
とか黄色文字で一瞬表示するの止められないんだろうか
チラチラして鬱陶しい

implict remotingて何だと調べると互換性の無いモジュールを裏でpowershell 5 を起動して処理してるんだとか
Set-Location 程度でも発動する

**デフォルトの名無しさん** · 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がエイリアスって件だけは俺も擁護できない
あの罠は誰もが一度は引っかかる